Guia Bsico sobre Princpios de Programao eSOLID

Estudando um pouco sobre Clean Code e boas prticas no desenvolvimento de software, me deparei com os princpios de programao e princpios SOLID. Aliados com o Clean Code, eles so uma ferramenta poderosa para mantermos um cdigo de fcil entendimento, fcil refatorao e com o menor nmero possveis de bugs.

Princpios de programao so recomendaes concretas que os desenvolvedores devem seguir para atender s propriedades de projeto. Cinco destes princpios formam os Princpios SOLID (em portugus, so eles: Responsabilidade nica, Aberto/Fechado, Substituio de Liskov, Segregao de Interfaces e Inverso de Dependncia). Estes princpios, aliados com as prticas de Clean Code, permite que desenvolvemos cdigos mais maleveis, que so mais fceis de se refatorar e melhorar. Vou descrever um pouco dos princpios do SOLID, alm de falar sobre o princpio de "Prefira Composio a Herana" e do princpio de "Demeter".

1. Princpio de Responsabilidade nica

Este princpio (relacionado a coeso) diz que cada classe (pode ser aplicado a funes, componentes, entidades entre outros) deve ter apenas uma responsabilidade, ou seja, deve existir apenas um motivo para modificar qualquer classe em um sistema.

Ou seja, este princpio prega que no devemos criar uma "Classe Deus" que, por exemplo, valida e-mail, l arquivo, acessa o banco de dados, grava no banco de dados, consulta uma API, entre outros. Como cada classe deve ter apenas uma funo, neste exemplo devemos ter uma classe apenas para acessar o banco de dados, outra apenas para ler um arquivo, outra para validar um e-mail e assim por diante, cada qual com sua funo.

2. Princpio Aberto/Fechado

Este princpio diz que uma classe deve estar fechada para modificaes e abertas para extenses. Seu objetivo a construo de classes flexveis e extensveis, capazes de se adaptarem a diversos cenrios de uso sem modificaes no seu cdigo fonte.
Neste princpio, o projeto da classe possibilita extenses e customizaes, atravs do uso de herana, funes de mais alta ordem (ou funes lambda) e padres de projeto (como Abstract Factory, Template Method, Strategy).

3. Princpio da Segregao de Interface

Este princpio define que as interfaces tm que ser pequenas, coesas e especificas para cada tipo de cliente. Trata-se de um caso particular de Responsabilidade nica com foco em interfaces (relacionado a coeso tambm), o objetivo deste princpio evitar que clientes dependam de interfaces com mtodos que eles no iro usar.

Ou seja, se voc no for utilizar algum dos mtodos daquela interface na classe que pretende implement-la, melhor criar uma nova interface especfica para aquela classe do que sobrescrever mtodos que no sero utilizados.

4. Princpio da Substituio de Liskov

Este princpio explicita regras para redefinio de mtodos de classes bases em classes filhas. Apesar de herana no ser muito utilizada, ela pode ser til em alguns casos especficos. A sua vantagem que comportamentos (mtodos) comuns a classe base e subclasses podem ser implementados uma nica vez (na classe base) e podero ser herdados em todas as subclasses.

Alguns exemplos de classes que violam este princpio so aquelas que sobrescrevem ou implementam (atravs de uma interface) mtodos que no fazem nada (pois alguns mtodos desta interface s est sendo utilizado por uma outra classe especfica, por exemplo), lana uma exceo inesperada, ou que retorna valores de tipos diferentes da classe base.

5. Princpio de Inverso de Dependncia

Este princpio recomenda que uma classe cliente deve estabelecer dependncias prioritariamente com abstraes e no com implementaes concretas, pois as abstraes (interfaces) so mais estveis do que implementaes concretas (classes).

A ideia levantada por este princpio ento de inverter as dependncias, ou seja, ao invs dos clientes dependerem de classes concretas, eles devem depender de interfaces. A vantagem deste princpio que, quando um cliente se acopla a uma interface, ele fica imune a mudanas na implementao dessa interface.

6. Prefira Composio a Herana

Este princpio recomenda o uso de composio a herana, pois quando usamos herana, isso acaba gerando um forte acoplamento entre superclasses e subclasses. A herana expe para subclasses detalhes de implementao das classes, fazendo com que a implementao das subclasses se torna to acoplada implementao da classe pai, que qualquer mudana nelas pode forar modificaes nas subclasses. Uma outra vantagem de se utilizar composio que a relao entre as classes no esttica, permitindo assim, fazer mudanas em tempo de execuo.

7. Princpio de Demeter

Este princpio defende que a implementao de um mtodo deve invocar apenas os seguintes outros mtodos:

• Da sua prpria classe (caso 1);
• De objetos passados como parmetros (caso 2);
• De objetos criados pelo prprio mtodo (caso 3);
• De atributos da classe do mtodo (caso 4);

O objetivo deste princpio evitar problemas de encapsulamento em projeto de sistemas orientados a objetos, ele recomenda que os mtodos de uma classe devem falar apenas com mtodos da prpria classe ou com mtodos de objetos que eles recebem como parmetros (ou que eles criam).