You are on page 1of 3

O que são Design Patterns?

Por Equipe para Programação.
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, um blog que 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.

http://www.princiweb.com.br/blog/programacao/o-que-sao-design-patterns/