Design Patterns

Também chamados de 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.

São soluções de templates abstratos de alto nível. São "blueprints" para soluções e não uma solução por si própria.

O conjunto dos mais conhecidos design patterns estão catalogados no livro "Design Patterns: Elements of Reusable Object-Oriented Software", mais conhecido como "A bíblia dos Design Patterns". Foi escrito por Erich Hamma, Richard Helm, Ralph Johnson e John Vlissdes, conhecidos como Gang of Four (GoF).

Eles coletaram 23 Design Patterns e os organizaram em 3 grupos:

Creational Patterns ou Padrões de Criação

Tratam da construção do objeto e o de referência.

Structural Patterns ou Padrões Estruturais

Tratam da relação entre objetos e como eles interagem entre si para formarem grandes objetos complexos.

Behavioral Patterns ou Padrões Comportamentais

Tratam da comunicação entre os objetos, especialmente em termos de responsabilidade e de algoritmos.

Utilidade

Seu valor reside no fato que eles foram soluções utilizadas e testadas, o que proporciona confiança em sua eficácia.

Design Patterns focam na reutilização de soluções. Ao quebrar problemas em partes menores, é possível encontrar Design Patterns para resolvê-los.

Princípios comuns de design

Keep It Simple Stupid (KISS)

Mantenha o código simples, mas não seja simplista. Evite a complexidade desnecessária.

Don't repeat yourself (DRY)

Evite a repetição de qualquer parte do sistema abstraindo as coisas que são comuns entre si e colocá-las em um lugar único.

Tell, don't ask

Está estreitamente alinhado com o encapsulamento e a atribuição de responsabilidades para as suas classes corretas. 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.

You ain't gonna need it (YAGNI)

Refere-se a necessidade de adicionar somente as funcionalidades que são necessárias para a aplicação deixar de lado qualquer tentação de adicionar outras funcionalidades que você acha que precisa. O Test Driven Development, ou desenvolvimento orientado a testes, adere ao YAGNI. TDD se baseia na escrita de testes que comprovam a funcionalidade do sistema e então escrevem somente o código para obter êxito no teste.

Separation Of Concerns (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. O ato de separar um programa em discretas responsabilidades aumenta significativamente a reutilização de código, manutenção e testabilidade.

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