DevMedia
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
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 como acessar este post

1) Torne-se um assinante MVP e por apenas R$ 69,90 por mês você terá acesso completo a todos os posts. Assinar MVP

2) Adquira Créditos: comprando R$ 180,00 em créditos esse post custará R$ 1,20. Comprar Créditos

Artigo .net Magazine 50 - Design Patterns – Parte 4

Veremos nesse artigo os problemas que o Factory Method não resolveu, mas que seu primo irmão Abstract Factory resolverá.

[fechar]

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

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

Confirmo meu voto negativo

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

ContextoDeJogo

Prepara e encerra o jogo, solicita a criação dos objetos do tipo Lutador com base em parâmetros recebidos, configura a cor da janela de console, informa sobre o Local, agita as Pessoas presentes à luta, realiza Sons, Prepara os lutadores e configura seus oponentes.

Lutador

Se prepara, pula, realiza 2 tipos diferentes de golpes. Possui um nome e um oponente configurado. Tudo potencialmente, na prática não programa nenhuma dessas ações, deixando para as classes herdeiras esse trabalho.

ContextoDeJogoFase1 e ContextoDeJogoFase2

Criam os lutadores de acordo com o parâmetro recebido e criam a arena de jogo, configurando o Local, as Pessoas e os Sons.

Agil, Forte, Ninja e Espadachim

Implementam concretamente as ações definidas pela classe Lutador.

Tabela 1. Responsabilidades de cada classe

 

Listagem 1. Código de testes do jogo com Factory Method

Module Module1

 

    Sub Main()

 

        While True

            Console.WriteLine("Escolha a fase 1, 2 ou para sair:")

            Dim strResponse = Console.ReadLine()

            Console.WriteLine()

            Select Case strResponse

                Case "1"

                    JogarFase1()

                Case "2"

                    JogarFase2()

"

A exibição deste artigo foi interrompida

Este post está disponível para assinantes MVP.



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?
Serviços

Mais posts