Nossas aplicações orientadas a objetos devem seguir princípios básicos de desenvolvimento, tais princípios são comumente intitulados como “Princípios de Projetos Orientados a Objetos”. Tais princípios são conceitos básicos que devemos nos guiar para desenvolvermos aplicações reutilizáveis, desconectadas, bem modeladas e “inteligentes”. Tais princípios foram à base para a construção de diversos catálogos de padrões  (Design Patterns), tais como: GoF e GRASP.

Os Princípios de Projetos Orientados a Objetos são:

Programe para interfaces, não para implementações: Programar para uma interface significa, na verdade, programar para um supertipo, uma classe abstrata ou uma interface de construção. A vantagem desse princípio é explorar o polimorfismo de modo que o objeto fique vinculado à abstração e diminua a quantidade de interdependências.

Utilize designs levemente ligados entre objetos que interagem: Projetos levemente acoplados são mais fáceis de serem modificados e muito mais flexíveis, pois minimizam a interdependência entre os objetos. Este é um dos princípios mais importantes na construção de Projetos Orientados a Objetos.

Dependa de abstrações. Não dependa de classes concretas: Também conhecido como Princípio da Inversão de Dependência, afirma que nenhuma variável ou atributo deve conter uma referência a uma classe concreta e, que nenhuma classe deve derivar de uma classe concreta. Dessa forma, conseguimos diminuir a interdependência de classes concretas e favorecer o desacoplamento entre as mesmas.

Encapsule o que varia: Este princípio possui um conceito simples que forma a base de quase todos os padrões de projeto. Ele defende a idéia de separar as partes que variam e encapsulá-las para que seja possível alterar ou estender essas partes sem afetar as que não variam. Assim é possível que uma parte de um sistema varie independentemente de todas as outras. Isso acarreta um número menor de alterações de código e mais flexibilidade nos sistemas.

Dê prioridade à composição em relação à herança: A utilização de composições proporciona interdependência entre os objetos e muito mais flexibilidade, pois permite a alteração do comportamento durante o tempo de execução, desde que o objeto que estivermos compondo, utilize a interface de comportamento correta.

As classes devem estar abertas para a extensão, mas fechadas para modificações: “Permitir que as classes sejam facilmente estendidas para incorporar um novo comportamento sem modificar o código existente. Assim, tornamos os projetos resistentes a mudanças e suficientemente flexíveis para assumir novos recursos para atender aos requisitos que mudam.” (Freeman, 2005, p. 86)

Mínimo Conhecimento: Também conhecido como Lei de Demétrio. O Princípio do Mínimo Conhecimento nos orienta a reduzir as interações entre os objetos, aconselhando-nos ao encapsulamento de funções, rotinas, lógicas internas e sistemas. Um sistema com muitas dependências entre múltiplas classes é um sistema frágil, de difícil manutenção e complexo demais para ser compreendido por todos.

“Isso significa que, ao projetarmos um sistema, devemos tomar cuidado com o número de classes com que qualquer objeto interage e também com a forma como essa interação ocorre (…) Este princípio nos impede de criar projetos com um grande número de classes interconectadas, o que faz com que qualquer alteração numa parte do sistema exerça um efeito em cascata sobre outras partes.” (Freeman, 2005, p. 221)

O princípio nos fornece algumas dicas: pegamos um objeto qualquer e, a partir de qualquer método para esse objeto, só podemos invocar métodos que pertençam ao próprio objeto, a objetos que tenham sido passados como parâmetros para o método, a qualquer objeto que seja criado ou instanciado pelo método e, finalmente, a quaisquer componentes do objeto.

Princípio de Hollywood – Não nos telefone, nós telefonaremos para você: “O princípio de Hollywood nos proporciona uma maneira de evitar o colapso das dependências (…). Colapso das dependências é o que acontece quando você tem componentes de alto nível dependendo de componentes de baixo nível que dependem de componente de alto nível que dependem de componentes laterais que dependem de componentes de baixo nível, e assim por diante.” (Freeman, 2005, p. 244)

Com este princípio, determinamos que componentes de baixo nível conectem-se ao sistema, mas são os componentes de alto nível que determinam quando e como eles serão solicitados.

“Em outras palavras, os componentes de alto nível dizem aos componentes de baixo nível: Não nos telefone, nós telefonaremos para você.” (Freeman, 2005, p. 244)

Uma classe só deve ter uma única razão para mudar: Uma classe que possua diversas responsabilidades não relacionadas ou executa muitas tarefas que deveriam ter sido delegadas a outras classes é indesejável e acarreta quatro problemas:
– Dificuldade de compreensão;
– Dificuldade de reutilização;
– Dificuldade de manutenção;
– Extremamente frágeis, sendo afetadas constantemente pelas mudanças.

Cada responsabilidade é uma área de mudança em potencial. Mais de uma área de responsabilidade equivale a mais de uma área de mudança. Este princípio nos ensina a limitar cada classe a uma única responsabilidade.

Referências:

FREEMAN, Eric, FREEMAN, Elisabeth; Head First – Design Patterns; O’Reilly Media;  Editora Alta Books Ltda; 2ª Edição Revisada; 2005.

GoF – HELM, Richard; VLISSIDES, John; JOHNSON , Ralph; GAMMA , Erich; Design Pattern – elements of reusable object-oriented software; BookMan; 1995.

LARMAN, Craig; Applying UML and patterns: an introduction to object-oriented analysis and design and the unified process; BookMan; 2004.