Software Design Patterns
Meu objetivo com esta artigo é te dar uma introdução sobre o que é Design Patterns, de onde eles vieram, como se originou, porque dos patterns e ajudar você a compreender um pouco mais sobre como resolver alguns problemas de forma mais eficiente, elegante e te deixar um pouco mais consciente do código que você escreve.
Design Patterns
Design Patterns (Padrões de Projeto) surgiram com a motivação de ajudar a solucionar problemas que ocorrem frequentemente, e se usado com bom senso, podem se tornar ferramentas poderosas para qualquer desenvolvedor de software.
Design patterns são soluções de templates abstratas de alto nível. Pense nelas como um “blueprint” (desenho técnico ou documentação de uma arquitetura, etc.) para soluções e não como uma solução para si própria.
Você não achará um framework com um design pattern específico para sua aplicação, os design patterns se aplicam para problemas que você e outros desenvolvedores também tenham em comum.
Você terá a necessidade de utilizar um design pattern quando estiver refatorando seu código e/ou generalizando seu problema.
Design patterns não são somente aplicados a desenvolvimento de software, eles podem ser encontrados em diversas áreas da nossa vida, da engenharia até a arquitetura.
Um arquiteto chamado “Christopher Alexander” introduziu a ideia de pattern em 1977 para construir um vocabulário comum para discuções sobre design. Ele escreveu:
Cada pattern descreve um problema que ocorre várias vezes ao nosso redor e com isso, descrevem a solução para o problema de uma maneira que você pode usar essa solução diversas vezes sem ter que fazer a mesma coisa duas ou mais vezes.
E porque Patterns?
Ai vem aquela famosa frase: “Padrão é bom porque cada um faz o seu!”
Os patterns foram pensados um pouco diferente desta frase ai, um pattern é uma solução de reuso que pode ser aplicada em problemas comuns em design de software, mas é importante saber qual a importância dos patterns e porque deveriamos nos familiarizar com eles.
Abaixo segue alguns motivos do porque os Design Pattern são diferente da frase citada acima:
- Patterns são soluções provadas: Como citado anteriormente, eles fornecem abordagens sólidas para resolver problemas no desenvolvimento de software usando técnicas comprovadas que refletem a experiência e os conhecimentos do desenvolvedor.
- Patterns podem ser facilmente reutilizado: Um padrão geralmente reflete uma solução fora da caixa que pode ser adaptada para atender às nossas próprias necessidades. Esse recurso os torna bastante robustos.
- Patterns podem ser expressivos: Quando olhamos para um padrão, geralmente existe uma estrutura definida e um vocabulário para a solução apresentada que pode ajudar a expressar soluções maiores de forma mais elegante.
Origem dos Design Patterns
As origens dos design patterns que permanecem hoje da arquitetura de software nasceram das experiências e conhecimento dos desenvolvedores utilizando programação orientada a objetos. O conjunto dos design patterns mais conhecidos estão catalogados no livro “Design Patterns: Elements of Reusable Object-Oriented Software”. Os autores desse livro, Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, são conhecidos como a “Gangue dos Quatro” (Gang of Four) ou simplesmente “GoF”.
Eles coletaram 23 patterns e organizaram em 3 grupos
- Creational Patterns (Padrão de criação) - tratam da construção do objeto.
- Structural Patterns (Padrões Estruturais) - tratam da relação entre os objetos e como eles interagem intre si para formarem grandes objetos complexos.
- Behavioral Patterns (Padrões Comportamentais) - tratam da comunicação entre os objetos especialmente em termos de responsabilidades e de algoritmos.
Veja abaixo os 23 patterns separados por suas classificações:
Creational Patterns — Com base no conceito de criar um objeto.
- Factory Method — Isso cria uma instância de diversas classes com base em dados ou eventos interconectados
- Abstract Factory — Cria uma instância de diversas famílias de classes sem detalhar classes concretas.
- Builder — Separa a construção do objeto de sua representação, sempre criar o mesmo tipo de objeto.
- Prototype — Uma instância totalmente inicializada usada para copiar ou clonar.
- Singleton — Uma classe com uma única instância e fornece um pontos de acesso global a ela.
Structural Patterns — Com base na ideia de construir blocos de objetos.
- Adapter — Bate com interfaces de diferentes classes, portanto, as classes podem funcionar juntas, apesar das interfaces incompatíveis.
- Bridge — Separa a interface de um objeto de sua implementação para que os dois possam funcionar de forma independente.
- Composite — Uma estrutura de objetos simples e composto que torna o objeto total mais do que a soma de suas partes.
- Decorator — Adicione dinamicamente processamento alternatido aos objetos.
- Facade — Uma única classe que esconde a complexidadde de um subsistema inteiro.
- Flyweight — Uma instância específica usada para o compartilhamento eficiente de informações contidas em outros lugares.
- Proxy — Um objeto titular que representa o objeto verdadeiro.
Behavioral Patterns — Com base na forma como os objetos jogam e trabalham em conjunto.
- Interpreter — Uma maneira de incluir elementos de idiomas em um aplicativo para combinar a gramática do idioma pretendido.
- Template Method — Cria o shell de um algorítmo em um método, depois adia os passos exatos para uma subclasse.
- Chain of Responsibility — Uma maneira de transmitir um pedido entre uma cadeia de objetos para encontrar o objeto que pode lidar o pedido.
- Command — Encapsula uma solicitação de comando como um objeto para ativar, registrar e/ou fazer filas de solicitações e fornece tratamento de erro para solicitações não tratadas.
- Iterator — Acessa sequencialmente os elemento de uma coleção sem conhecer o funcionamento interno da coleção.
- Mediator — Define uma comunicação simplificada entre classes para evitar que um grupo de classes se refira explicitamente entre si.
- Memento — Captura o estado interno de um objeto para poder restaurá-lo em um outro momento.
- Observer — Uma maneira de notificar a mudança para várias classes para garantir a consistência entre elas.
- State — Alreta o comportamento de um objeto quando seu estado muda.
- Strategy — Encapsula um algorítmo dentro de uma classe que separa a seleção da implementação.
- Visitor — Adiciona uma nova operação a uma classe sem alterar a classe.
Não acaba por aqui, pretendo nos próximos artigos abordar cada um dos patterns a nível de implementação, este artigo foi apenas uma introdução para mais 23 outros artigos abordando cada padrão, entendendo porque utilizar, quando utilizar e espero que vocês acompanhem esta série.
Até mais.
