DevMedia - asp.net, Java, Delphi, SQL e web Design, tudo em um só lugar!
Bem vindo a DevMedia!
LOGIN:     SENHA:
 
 

  Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da .net Magazine DIGITAL
ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!

Artigo .net Magazine 50 - Design Patterns – Parte 4

Artigo publicado pela Revista .Net Magazine - Edição 50.

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você gostaria de comentar o que não lhe agradou?

Esse artigo faz parte da revista .NET Magazine edição 50. Clique aqui para ler todos os artigos desta edição


 

Expert - Boas Práticas

Design Patterns – Parte 4

Abstract Factory

 

 

Chegamos ao quarto artigo da série de Design Pattern já tendo visto os padrões Strategy, Decorator, Template Method e Factory Method. A essa altura você já confirmou o que afirmei no primeiro artigo: design patterns podem mudar radicalmente a sua forma de codificar. Você já está pensando duas vezes antes de criar um desenho baseado em herança, e considera antes se a composição não seria uma melhor opção, utilizando o padrão Strategy ou Decorator. E quando utiliza herança, tem a sua disposição ferramentas poderosas como o padrão Template Method e o Factory Method, vistos no último artigo.

Seguiremos neste artigo explorando os problemas do “new”. Busque a edição anterior da revista e tente lembrar porque o “new” pode nos trazer problemas. Lembre-se dos problemas que resolvemos com o padrão Factory Method. Veremos agora os problemas que o Factory Method não resolveu, mas que seu “primo irmão” Abstract Factory resolverá. Os dois padrões são muito parecidos, abordam necessidades parecidas, mas atendem estas necessidades de forma diferente, porque afinal, parecido não é igual. De tão parecidos, muitos os tomam por um só padrão, como se houvesse somente um único padrão “Factory”.

 

Onde paramos

É uma boa idéia revisar o que foi feito no artigo anterior. Iniciamos o artigo com um aplicativo de jogo, com classes de contexto de jogo e de lutadores. O aplicativo era plenamente funcional, mas tinha sérios problemas de dependência, alto acoplamento, e muita dificuldade para realizar qualquer tipo de mudança. Ao longo do artigo refatoramos muitos de seus métodos e revimos suas camadas. O diagrama de classes do artigo ficou, ao final, como o da Figura 1. A Tabela 1 mostra o que cada classe faz e suas responsabilidades. A Listagem 1 mostra o código de teste, e nos permite lembrar mais claramente as interfaces do objeto de contexto de jogo e lutador.

 

Figura 1. Diagrama de classes com implementação do Factory Method

 

Classe

Responsabilidade

"
A exibição deste artigo foi interrompida.

  Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da .net Magazine DIGITAL
ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!


Giovanni Bassi
Giovanni Bassi (giggio@giggio.net) é MCAD .Net e trabalha com a plataforma .Net há 3 anos. Trabalha com coordenação, análise e desenvolvimento de software e ministra treinamentos e palestras sobre .NET.
O que você achou deste post?

    0 COMENTÁRIO

[Fechar]

Este post é fechado - você precisa ter acesso ao post para incluir um comentário.


Nenhum comentário foi postado - seja o primeiro a comentar!
Cursos relacionados
Publicidade
[Fechar]

Você precisa estar logado para dar um feedback.

Clique aqui para efetuar o login
[Fechar]


Este post está fechado. Saiba mais sobre a assinatura MVP!
web-03
DevMedia  |  Anuncie  |  Fale conosco
Hospedagem web por Porta 80 Web Hosting
2013 - Todos os Direitos Reservados a web-03