O que são Design Patterns

Prévia do material em texto

O que são Design Patterns?
Por Jéssica Schissato, Rodolfo Pereira | 12 de março, 2012 | 19 comentários
Design patterns (padrões de projeto) surgiram com a motivação de ajudar a solucionar problemas que ocorrem frequentemente, e, se usados com bom senso, podem se tornar ferramentas poderosas para qualquer desenvolvedor de software, uma vez que já foram testadas, utilizadas e aprimoradas a partir da experiência e conhecimento de outros programadores.
Preparamos um post explicando o que são design patterns e seus princípios comuns, baseado no livro “Professional ASP.NET Design Patterns” de Scott Millett.
Tirinha retirada do site Vida de Programador, o qual publica tirinhas diárias com histórias engraçadas e verídicas sobre o dia-a-dia de um programador.
Explicando Design Patterns
Design patterns (Padrões de projeto) 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 por si própria. Você não achará um framework que você poderá simplesmente aplicar para a sua aplicação; ao invés disso, você chegará ao design patterns através da refatoração do seu código e generalização do seu problema.
Design patterns não são somente aplicados em desenvolvimento de software; design patterns podem ser encontrados em diversas áreas da vida, da engenharia até da arquitetura. Em fato, foi o arquiteto Christopher Alexander que introduziu a ideia de patterns em 1970 para construir um vocabulário comum para discussõ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.
Origem
As origens do design patterns que prevalecem hoje na arquitetura de software nasceram das experiências e conhecimento dos programadores utilizando a programação orientada a objeto. O conjunto dos mais conhecidos design patterns estão catalogados no livro chamado “Design Patterns: Elements of Reusable Object-Oriented Software”, mais conhecido como “Design Patterns Bible”. Esse livro foi escrito por Erich Hamma, Richard Helm, Ralph Johson e John Vlissdes, mais conhecidos como “Gang of Four”.
Eles coletaram 23 design patterns e organizaram em 3 grupos:
Creational Patterns (Padrões de Criação): Tratam da construção do objeto e o de referência;
Structural Patterns (Padrões Estruturais): Tratam da relação entre objetos e como eles interagem entre sim para formarem grandes objetos complexos;
Behavioral Patterns (Padrões Comportamentais): Tratam da comunicação entre os objetos, especialmente em termos de responsabilidade e de algoritimos.
Utilidade
O valor dos design patterns reside no fato que eles são soluções que foram utilizadas e testadas, o que nos dá confiança em sua eficácia.
Design patterns focam na reutilização de soluções. Todos os problemas não são iguais, mas se você puder “quebrar” o problema e achar similiaridades com problemas que você já resolveu antes, você pode aplicar essas soluções. Depois de décadas de programação orientada a objeto, a maioria dos problemas que você encontrará já terão sido resolvidas no passado, e haverá um pattern disponível para ajudar você na implementação da solução. Mesmo se você acredita que o seu problema é único, ao quebrá-lo em pequenas partes, você será capaz de generalizá-lo o suficiente para encontrar a solução apropriada.
O nome dos design patterns são úteis porque refletem o seu comportamento e propósito, e fornecem um vocabulário comum em um brainstorming de solução. É muito mais fácil falarmos em termos do nome do pattern do que detalhar sobre como essa implementação deveria funcionar.
O que eles não são
Design patterns não são a bala de prata (solução de todos os problemas). Você deve ter o entendimento geral do seu problema, generalizá-lo e então aplicar o pattern apropriado para a solução desse problema. Porém, nem todos os problemas requerem um design pattern. É verdade que o design pattern pode ajudar a tornar problemas complexos em problemas simples, porém eles também podem tornar problemas simples em problemas complexos.
Princípios comuns de design
Há diversos princípios comuns de design, que, assim como os design patterns, se tornaram boas práticas através dos anos e ajudaram a formar uma fundação no qual o nível empresarial e software de fácil manutenção podem ser construídos. Abaixo, segue um resumo dos princípios mais conhecidos:
Keep It Simple Stupid (KISS)
Mantenha Isto Estupidamente Simples
Um problema comum em programação de software é a necessidade de complicar demais a solução. O objetivo do princípio KISS é manter o código simples, mas não simplista, assim evitando complexidade desnecessária.
Don’t Repeat Yourself (DRY)
Não Repita Você Mesmo
O princípio do DRY é evitar a repetição de qualquer parte do sistema abstraindo as coisas que são comuns entre si e colocá-las em um lugar único. Esse princípio não se preocupa somente com o código, mas qualquer lógica que está duplicada no sistema.
Tell, Don’t Ask
Fale, não pergunte
O principio Tell, Don’t Ask está estreitamente alinhado com o encapsulamento e a atribuição de responsabilidades para as suas classes corretas. O princípio afirma que você deve dizer aos objetos quais ações você quer que eles realizem, ao invés de fazer perguntas sobre o estado do objeto e então tomar uma decisão por si próprio em cima da ação que você quer realizar. Isso ajuda a alinhar as responsabilidades e evitar o forte acoplamento entre as classes.
You Ain’t Gonna Need It (YAGNI)
Você Não Vai precisar Disso
O princípio YAGNI se refere a necessidade de adicionar somente as funcionalidades que são necessárias para a aplicação e deixar de lado qualquer tentação de adicionar outras funcionalidades que você acha que precisa. A metodologia de projeto que adere ao YAGNI é a test-driven development (TDD) – desenvolvimento orientado a testes. TDD se baseia na escrita de testes que comprovam a funcionalidade do sistema e então escrevem somente o codigo para obter êxito no teste.
Separation Of Concerns (SoC)
Separação de Responsabilidades
SoC é o processo de dissecação de uma parte de software em distintas características que encapsulam um único comportamento e dados que podem ser utilizados por outras classes. Geralmente, a responsabilidade representa uma características ou comportamento da classe. O ato de separar um programa em discretas responsabilidades aumenta significativamente a reutilização de código, manutenção e testabilidade.