Design Patterns são Padrões de Projetos que foram surgindo durante as experiências de diversos projetos de softwares, principalmente depois da adoção em massa da programação orientada a objeto. Os padrões se tornaram de conhecimento público quando os engenheiros de softwares Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides decidiram estabelecer e catalogar os problemas mais comuns e as formas de resolvê-los. Foi aí que, em 1994, lançaram o livro “Design Patterns: Elements of Reusable Object – Oriented Software”, que acabou virando uma espécie de bíblia sobre o assunto. O quarteto ficou conhecido como “Gang of Four” ou simplesmente GoF.
Um padrão descreve um conjunto composto por um contexto, um problema e uma solução. Em outras palavras, pode-se descrever um padrão como uma solução para um determinado problema em um contexto. Porém um padrão não descreve qualquer solução, mas uma solução que já tenha sido utilizada com sucesso em mais de um contexto. Exatamente por esse motivo que a descrição dos padrões normalmente sempre indica alguns de seus usos conhecidos. Um padrão não descreve soluções novas, mas soluções consolidadas.
Conhecer diversas soluções sem precisar passar por vários anos alternando entre escolhas certas e erradas. Saber o contexto em que essas soluções são adequadas e quais são as contrapartidas dos benefícios da solução?
Há várias formas de classificar os padrões. Gamma et al os classifica de duas formas:
- Por propósito:
- criação de classes e objetos,
- alteração da estrutura de um programa,
- controle do seu comportamento.
- Por escopo: classe ou objeto.
Metsker os classifica em 5 grupos, por intenção (problema a ser solucionado):
- oferecer uma interface,
- atribuir uma responsabilidade,
- realizar a construção de classes ou objetos,
- controlar formas de operação,
- implementar uma extensão para a aplicação.
| Propósito | ||||
|---|---|---|---|---|
| 01. Criação | 02. Estrutura | 03. Comportamento | ||
| Escopo | Classe | Factory Method | Class Adapter | Interpreter Template Method |
| Objeto | Abstract Factory | Object Adapter | Chain of Responsibility | |
| Builder | Bridge | Command | ||
| Prototype | Composite | Iterator | ||
| Singleton | Decorator | Mediator | ||
| Facade | Memento | |||
| Flyweight | Observer | |||
| Proxy | State | |||
| Strategy | ||||
| Visitor | ||||
Os padrões criacionais fornecem vários mecanismos de criação de objetos, que aumentam a flexibilidade e reutilização de código já existente.
-
Factory Method, também conhecido como "Método fábrica", "Construtor virtual" é um padrão criacional de projeto que fornece uma interface para criar objetos em uma superclasse, mas permite que as subclasses alterem o tipo de objetos que serão criados.
-
Abstract Factory permite que você produza famílias de objetos relacionados sem ter que especificar suas classes concretas.
-
Builder permite construir objetos complexos passo a passo. O padrão permite produzir diferentes tipos e representações de um objeto usando o mesmo código de construção.
-
Prototype permite que você copie objetos existentes sem fazer seu código ficar dependente de suas classes.
-
Singleton permite a você garantir que uma classe tem apenas uma instância, enquanto provê um ponto de acesso global para esta instância.
Os padrões estruturais são os que tratam da relação entre os objetos e como eles interagem entre si para formarem objetos grandes e complexos.
-
Class Adapter usa herança e só pode encapsular uma classe. Ele não pode agrupar uma interface, pois, por definição, deve derivar de alguma classe base. Essa abordagem só pode ser implementada em linguagens de programação que suportam herança múltipla, tais como C++.
-
O Object Adapter usa o princípio de composição do objeto e pode agrupar classes ou interfaces, ou ambos. Ele pode fazer isso, pois contém, como um membro privado e encapsulado, a classe ou a instância do objeto de interface que envolve. Essa abordagem pode ser implementada em várias linguagens de programação, incluindo C#.
-
Bridge permite que você divida uma classe grande ou um conjunto de classes intimamente ligadas em duas hierarquias separadas — abstração e implementação — que podem ser desenvolvidas independentemente umas das outras.
-
Composite permite que você componha objetos em estruturas de árvores e então trabalhe com essas estruturas como se elas fossem objetos individuais.
-
Decorator permite que você acople novos comportamentos para objetos ao colocá-los dentro de invólucros de objetos que contém os comportamentos.
-
Facade simplifica a utilização de subsistemas complexos, fornecendo uma interface simplificada para uma biblioteca, um framework, ou qualquer conjunto complexo de classes.
-
Flyweight permite a você colocar mais objetos na quantidade de RAM disponível ao compartilhar partes comuns de estado entre os múltiplos objetos ao invés de manter todos os dados em cada objeto.
-
Proxy permite que você forneça um substituto ou um espaço reservado para outro objeto. Um proxy controla o acesso ao objeto original, permitindo que você faça algo ou antes ou depois do pedido chegar ao objeto original.
-
O Template Method é um padrão de projeto comportamental que define o esqueleto de um algoritmo na superclasse mas deixa as subclasses sobrescreverem etapas específicas do algoritmo sem modificar sua estrutura.
-
O Chain of Responsibility é um padrão de projeto comportamental que permite que você passe pedidos por uma corrente de handlers. Ao receber um pedido, cada handler decide se processa o pedido ou o passa adiante para o próximo handler na corrente.
-
O Command é um padrão de projeto comportamental que transforma um pedido em um objeto independente que contém toda a informação sobre o pedido. Essa transformação permite que você parametrize métodos com diferentes pedidos, atrase ou coloque a execução do pedido em uma fila, e suporte operações que não podem ser feitas.
-
O Iterator é um padrão de projeto comportamental que permite a você percorrer elementos de uma coleção sem expor as representações dele (lista, pilha, árvore, etc.)
-
O Mediator é um padrão de projeto comportamental que permite que você reduza as dependências caóticas entre objetos. O padrão restringe comunicações diretas entre objetos e os força a colaborar apenas através do objeto mediador.
-
O Memento é um padrão de projeto comportamental que permite que você salve e restaure o estado anterior de um objeto sem revelar os detalhes de sua implementação.
-
O Observer é um padrão de projeto comportamental que permite que você defina um mecanismo de assinatura para notificar múltiplos objetos sobre quaisquer eventos que aconteçam com o objeto que eles estão observando.
-
O State é um padrão de projeto comportamental que permite que um objeto altere seu comportamento quando seu estado interno muda. Parece como se o objeto mudasse de classe.
-
O Strategy é um padrão de projeto comportamental que permite que você defina uma família de algoritmos, coloque-os em classes separadas, e faça os objetos deles intercambiáveis.
-
O Visitor é um padrão de projeto comportamental que permite que você separe algoritmos dos objetos nos quais eles operam.
| Intenção | Padrões |
|---|---|
| 1. Interfaces | Adapter, Facade, Composite, Bridge |
| 2. Responsabilidade | Singleton, Observer, Mediator, Proxy, Chain of Responsibility, Flyweight |
| 3. Construção | Builder, Factory Method, Abstract Factory, Prototype, Memento |
| 4. Operações | Template Method, State, Strategy, Command, Interpreter |
| 5. Extensões | Decorator, Iterator, Visitor |
Usarei essa classificação nos meus estudos.
A utilização dos padrões de projeto representam um ganho de produtividade, pois evitam que sejam desperdiçados tempo e energia para solucionar problemas em comum. O seu uso também contribui para uma melhor organização e manutenção dos projetos. Além disso, as discussões técnicas se tornam mais sucintas, pois é mais fácil citar o nome de um Design Patterns ao invés de ter que explicar todo o seu comportamento e justificá-lo. É importante, porém, ter bom senso ao utilizá-los. Apesar do seu objetivo ser ajudar e facilitar os processos, existem casos em que não devem ser utilizados. Portanto, é ideal avaliar com cautela cada situação.
GUERRA, Eduardo. Design Patterns com Java: Projeto orientado a objetos guiado por padrões. Casa do Código, 2014.
SHVETS, Alexander. Mergulo nos Padrões de Projeto. Refactoring Guru, 2021.
Hostgator. Conheça os diferentes tipos de Design Patterns e seus benefícios. Disponível em: https://www.hostgator.com.br/blog/design-patterns-e-seus-beneficios/. Acesso em 14 de maio de 2023.