Vous êtes sur la page 1sur 3

O que so Design Patterns?

Por Equipe para Programao.


Design patterns (padres de projeto) surgiram com a motivao 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
experincia e conhecimento de outros programadores.
Preparamos um post explicando o que so design patterns e seus princpios comuns, baseado no livro
Professional ASP.NET Design Patterns de Scott Millett.

Tirinha retirada do site Vida de Programador, um blog que publica tirinhas dirias com histrias
engraadas e verdicas sobre o dia-a-dia de um programador.
Explicando Design Patterns
Design patterns (Padres de projeto) so solues de templates abstratas de alto nvel. Pense nelas
como um blueprint (desenho tcnico ou documentao de uma arquitetura, etc.) para solues e no
como uma soluo por si prpria. Voc no achar um framework que voc poder simplesmente aplicar
para a sua aplicao; ao invs disso, voc chegar ao design patterns atravs da refatorao do seu
cdigo e generalizao do seu problema.
Design patterns no so 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 vocabulrio comum
para discusses sobre design. Ele escreveu:
Cada pattern descreve um problema que ocorre vrias vezes ao nosso redor e com isso, descrevem a
soluo para o problema de uma maneira que voc pode usar essa soluo 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 experincias
e conhecimento dos programadores utilizando a programao orientada a objeto. O conjunto dos mais
conhecidos design patterns esto 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 (Padres de Criao): Tratam da construo do objeto e o de referncia;
Structural Patterns (Padres Estruturais): Tratam da relao entre objetos e como eles interagem
entre sim para formarem grandes objetos complexos;
Behavioral Patterns (Padres Comportamentais): Tratam da comunicao entre os objetos,
especialmente em termos de responsabilidade e de algoritimos.
Utilidade
O valor dos design patterns reside no fato que eles so solues que foram utilizadas e testadas, o que
nos d confiana em sua eficcia.
Design patterns focam na reutilizao de solues. Todos os problemas no so iguais, mas se voc
puder quebrar o problema e achar similiaridades com problemas que voc j resolveu antes, voc pode
aplicar essas solues. Depois de dcadas de programao orientada a objeto, a maioria dos problemas
que voc encontrar j tero sido resolvidas no passado, e haver um pattern disponvel para ajudar voc
na implementao da soluo. 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 soluo apropriada.
O nome dos design patterns so teis porque refletem o seu comportamento e propsito, e fornecem um
vocabulrio comum em um brainstorming de soluo. muito mais fcil falarmos em termos do nome do
pattern do que detalhar sobre como essa implementao deveria funcionar.
O que eles no so
Design patterns no so a bala de prata (soluo de todos os problemas). Voc deve ter o entendimento
geral do seu problema, generaliz-lo e ento aplicar o pattern apropriado para a soluo desse problema.
Porm, nem todos os problemas requerem um design pattern. verdade que o design pattern pode
ajudar a tornar problemas complexos em problemas simples, porm eles tambm podem tornar
problemas simples em problemas complexos.
Princpios comuns de design
H diversos princpios comuns de design, que, assim como os design patterns, se tornaram boas prticas
atravs dos anos e ajudaram a formar uma fundao no qual o nvel empresarial e software de fcil
manuteno podem ser construdos. Abaixo, segue um resumo dos princpios mais conhecidos:
Keep It Simple Stupid (KISS)
Mantenha Isto Estupidamente Simples
Um problema comum em programao de software a necessidade de complicar demais a soluo. O
objetivo do princpio KISS manter o cdigo simples, mas no simplista, assim evitando complexidade
desnecessria.
Dont Repeat Yourself (DRY)
No Repita Voc Mesmo
O princpio do DRY evitar a repetio de qualquer parte do sistema abstraindo as coisas que so
comuns entre si e coloc-las em um lugar nico. Esse princpio no se preocupa somente com o cdigo,
mas qualquer lgica que est duplicada no sistema.
Tell, Dont Ask
Fale, no pergunte
O principio Tell, Dont Ask est estreitamente alinhado com o encapsulamento e a atribuio de
responsabilidades para as suas classes corretas. O princpio afirma que voc deve dizer aos objetos
quais aes voc quer que eles realizem, ao invs de fazer perguntas sobre o estado do objeto e ento
tomar uma deciso por si prprio em cima da ao que voc quer realizar. Isso ajuda a alinhar as
responsabilidades e evitar o forte acoplamento entre as classes.
You Aint Gonna Need It (YAGNI)
Voc No Vai precisar Disso
O princpio YAGNI se refere a necessidade de adicionar somente as funcionalidades que so necessrias
para a aplicao e deixar de lado qualquer tentao 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 ento escrevem somente o codigo para obter xito no teste.
Separation Of Concerns (SoC)
Separao de Responsabilidades
SoC o processo de dissecao de uma parte de software em distintas caractersticas que encapsulam
um nico comportamento e dados que podem ser utilizados por outras classes. Geralmente, a
responsabilidade representa uma caractersticas ou comportamento da classe. O ato de separar um
programa em discretas responsabilidades aumenta significativamente a reutilizao de cdigo,
manuteno e testabilidade.

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