Princípios de padrões de projeto

Definição de Padrão de Desenho
Os padrões de projeto de software ou padrões de desenho de software, também muito conhecido pelo termo original em inglês: Design Patterns, descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um padrão de projeto estabelece um nome e define o problema, a solução, quando aplicar esta solução e suas conseqüências.
Referência: http://pt.wikipedia.org/wiki/Padrões_de_projeto_de_software

Princípios de Design (Design Principles)
Design Principles ou princípios de design representam um conjunto de orientações que nos ajuda a evitar uma concepção do desenho.

Abaixo uma lista com 3 características importantes de uma má concepção que devem ser evitadas:

• Rigidez: É difícil mudar, porque cada mudança afeta muitas outras partes do sistema;
• Fragilidade: Quando faz uma mudança inesperadamente partes do sistema começam a falhar;
• Imobilidade: É difícil reutilizar o componente em outro aplicativo;

Alguns princípios são descritos abaixo:

Princípio Aberto Fechado (Open Close Principle):
Definição: “Entidades de software como classes, módulos e funções devem ser abertas para expansão, mas fechadas para modificações”;

OPC é um princípio gernérico Quando se refere às classes o princípio Aberto Fechado pode ser assegurado através da utilização de classes abstratas e concretas para implementar alguns comportamentos. Alguns padrões que refletem esse princípio são Template Pattern e Strategy Pattern.

Princípio Inversão de Dependência (Dependency Inversion Principle)
Definição:

• “Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.”;

• “Abstrações não deve depender de detalhes. Detalhes devem depender abstrações.”.

Inversão de dependência ou de controle são termos relativos e são as melhores maneiras pela quais as dependências são realizadas. Na forma clássica, quando um módulo de software (classe, framerwork, ...) precisam de algum outro módulo, que inicializa e possui uma referência direta a ela, isso os tornará acoplados. A fim de separar o primeiro módulo do segundo e fornecer um gancho (propriedade, parâmetro, ...) um módulo externo controlando as dependências irá injetar uma referência ao segundo. Factory Pattern e Abstract Factories Pattern refletem esse princípio.

Princípio Segregação de Interfaces (Interface Segregation Principle)
Definição: “Os clientes não devem depender de interfaces que eles não usam”.

Este princípio nos ensina a cuidar da forma que escrevemos nossas interfaces. Quando escrevemos as nossas interfaces, deve-se ter o cuidado de só acrescentar métodos que deveriam estar lá. Se acrescentamos métodos que não deveriam estar lá as classes que à implementam teram que implementar esses métodos. Por exemplo, se vamos criar uma interface chamada Trabalho e adicionar um método de intervalo para o almoço, todos os trabalhadores terão de implementá-lo. E se o trabalhador é um robô?

Interfaces contendo métodos que não são específicas para isso são chamadas poluídas ou de gorduras interfaces. Devemos evitá-los.

Princípio Programe para uma interface, e não para uma implementação.
Este princípio é realmente sobre a dependência das relações que têm de ser cuidadosamente geridas de uma grande aplicação. É fácil adicionar uma dependência de uma classe, basta adicionar uma declaração de importação. Curiosamente o inverso não é tão fácil assim e se livrar de uma indesejada dependência pode dar muito trabalho. Por isso você tem que desenvolver com os olhos abertos quando se trata a introdução de dependências. Este princípio nos diz que, depender de uma interface é muitas vezes vantajoso.
Referência: Erich Gamma.