Aplicando os princípios SOLID com AdvPL/TL++ (Introdução)

Robert Martin reuniu a partir 1995, um conjunto de cinco princípios de orientação a objetos. De certa forma, os princípios eram conhecidos, porém foi Martin quem reuniu os mais importantes e posteriormente Michael Feathers, autor do livro "Trabalhando eficientemente com Código Legado", foi quem sugeriu o acrônimo SOLID.

Segundo o próprio Martin, os princípios do SOLID não são regras, não são leis e não são perfeitas, tratam-se de soluções de senso comum para problemas comuns. São recomendações que se utilizadas apropriadamente ajudam os desenvolvedores a construir soluções extensíveis, duradouras e de simples manutenção.

Quando descobri SOLID pela primeira vez, através de meu amigo Diogo Damiani, fiquei tentado a aplica-lo indiscriminadamente. Porém, percebi que o código final ficou super projetado, custoso e extenso demais. Foi ai que entendi o comentário acima do Martin — princípios não são regras. Assim, passei a aplica-lo naquilo que realmente importa. Neste momento, me recordei da experiência que tive com normalização de banco de dados e passei a entende-lo desta forma.

Concluída este ponto, o objetivo deste conjunto de artigos é falar um pouco sobre a pratica dos princípios SOLID passando pela teoria e demonstrando sua aplicação na linguagem AdvPL/TL++.

Legal, mas o que é SOLID? Trata-se de princípios aplicados ao paradigma da programação orientada a objetos com o objetivo de solucionar os problemas do cotidiano de um desenvolvedor, tais como:

• Melhorar a manutenção do código-fonte;
• Tornar o código-fonte mas simples de entender e testar;
• Melhorar a capacidade de reutilização do código-fonte;
• Reduzir o acoplamento;
• Eliminar a duplicação de código-fonte;

Em Resumo, fazer mais com menos!

Single Responsibility Principle

"Uma classe uma e somente uma razão para mudar, isto é, uma classe deve ter somente uma única responsabilidade."

O objetivo deste principio é combater a complexidade do código que surge quando você desenvolve um aplicativo. Quando este principio não é empregado, diversos problemas são gerados. O código torna-se difícil de compreender e consequentemente sua manutenção é difícil. A reutilização do código, não é tão simples quanto deveria, provocando a duplicação de código. A coesão do código pode ser comprometida quando as responsabilidades são entrelaçadas, alterar uma responsabilidade pode comprometer a outra e por fim, o alto acoplamento do código, representado pelo excesso de dependências, torna-o difícil de testar e frágil.

Class PedidoVenda From LongClassName

Method New() Constructor

Method AdicionaItem()

Method CalculaPedido()

Method ImprimePedido(oPedido)

Method AprovaPedido(oPedido)

EndClass

Na classe acima, podemos observar que a classe possui mais de uma responsabilidade. As responsabilidades encontradas são as de domínio do Pedido (AdicionaItem e CalculaPedido), Imprimir o Pedido e Aprovar o Pedido, sendo que estas duas ultimas, não necessariamente manipulam algo referente ao domínio do pedido, podendo serem separadas em outras duas classes, sem prejuízo ao software.

Entender a aplicar este principio (SRP), auxilia na qualidade do código-fonte e consequentemente na qualidade final do software. Apesar de ser um principio simples, em nosso cotidiano é possível identificar diversas classes ou entidades do software que não seguiram este principio.

Voltando ao comentário feito no inicio deste artigo: princípios não são regras, não consegui encontrar nenhum motivo para não aplicar este principio e apesar de ter negado ele no passado, hoje, tendo a não me orgulhar disto.

E você, porque não utiliza este princípio no seu cotidiano?