Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Na edição passada, foi iniciada uma discussão a respeito do uso de padrões de projetos no desenvolvimento de aplicações. Foram apresentados os objetivos a que se prestam estes mecanismos, bem como mencionadas vantagens que tais práticas oferecem.

São inúmeros os benefícios advindos do uso de padrões. A escolha pelos design patterns mais apropriados a um determinado contexto pode resultar em economia de recursos, bem como numa melhor estruturação da aplicação que se está contribuindo e, consequentemente, em uma maior facilidade para a condução de atividades futuras de manutenção. Outro ponto positivo obtido a partir da utilização destas técnicas, está na forte ênfase no reuso de soluções cuja eficácia já foi demonstrada anteriormente.

Merece destaque o fato de que os patterns de maior difusão no desenvolvimento de software estão fundamentados em conceitos de orientação a objetos, sendo uma prática comum à representação dos mesmos em diagramas da linguagem UML. Devido a estas características, diversos padrões podem ser empregados sem maiores transtornos em linguagens e plataformas bem heterogêneas como C#, VB.NET, Java, C++, Delphi etc.

Os patterns apresentados nesta série de artigos pertencem a um agrupamento de 23 padrões, conhecidos como GoF. Esta sigla é uma abreviação do termo (“Gang of Four”), sendo uma referência ao trabalho pioneiro de quatro autores (Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides) e que culminou no lançamento do conhecido livro “Design Patterns: Elements of Reusable Object-Oriented Software” em meados da década de 1990. Por mais que as diversas técnicas apresentadas nesta publicação sejam baseadas em exemplos codificados em C++ e Smalltalk, o largo escopo coberto por tais soluções auxilia ainda hoje desenvolvedores de modernas tecnologias, como .NET e Java (em problemas cotidianos, que serão visto a seguir).

Considerando o tipo de problema a que se propõe solucionar, os patterns GoF podem ser classificados em:

• Padrões de criação: Abstract Factory, Builder, Factory Method, Prototype e Singleton;

• Padrões estruturais: Adapter, Bridge, Composite, Decorator, Façade, Flyweight e Proxy;

• Padrões comportamentais: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method e Visitor.

É importante ressaltar que a própria plataforma .NET teve diversos de seus componentes básicos construídos em conformidade com alguns padrões GoF (alguns casos serão apresentados em seções subsequentes).

A finalidade deste artigo é dar andamento à abordagem iniciada na edição anterior, sendo que serão explicados em maior profundidade os seguintes patterns GoF:

• Abstract Factory;

• Adapter;

• Decorator;

• Iterator;

• Memento;

• Prototype;

• Strategy;

• Template Method.

Nota do DevMan

UML (sigla em inglês para "Unified Modeling Language") é uma linguagem voltada à modelagem de componentes de software e que se baseia em conceitos de orientação a objetos. Trata-se de uma notação que disponibiliza uma série de diagramas, sendo o de classes um dos mais conhecidos (este que será utilizado para a demonstração dos diversos patterns descritos neste artigo).

Abstract Factory

O padrão de criação Abstract Factory (Figura 1) promove o uso de uma interface (ou classe abstrata) que estará envolvida na geração de famílias de objetos relacionados (ou mesmo dependentes entre si), sem que se especifiquem as classes concretas das instâncias que serão criadas.

Graças a estas características, o consumidor de uma Abstract Factory não precisará ter conhecimento de todas as classes concretas que implementam a mesma ou ainda, dos produtos retornados por tal Factory.

As instâncias correspondentes às fabricas de objetos e aos produtos propriamente ditos, serão obtidas basicamente a partir de implementações concretas de interfaces e classes abstratas: os critérios para definir quais elementos servirão de base para a geração de referência, dependerá geralmente de informações de configuração ou mesmo, de alguma informação fornecida por um usuário da aplicação.

Nota do DevMan

Classes concretas: são classes que possuem atributos, métodos, construtores etc. As mesmas podem ser instanciadas, ou seja, permite a criação de objetos a partir dela.

Classes abstratas: são classes que servem como modelos para outras classes. Não pode ser instanciada. Na prática, você deve fazer com que classes concretas herdem de classes abstratas. Métodos abstratos codificados em uma classe abstrata devem obrigatoriamente ser implementados em uma classe concreta."

[...] continue lendo...