Programe melhor, pratique S.O.L.I.D.

Em ciência computacional, principalmente para quem trabalha com programação é fundamental entender e saber aplicar alguns paradigmas, dentre eles, Orientação a Objetos. No entanto, alguns conceitos e habilidades são diretamente entrelaçados e o bom entendimento são essenciais para qualidade de código, portanto, são exigidos aos profissionais de Análise e Desenvolvimento. Dentro deste contexto há um conjunto de princípios que ajudam e reforçam a aplicação de uma melhor qualidade de código, como também o uso correto dos conceitos de POO.

Assuntos como acoplamento, coesão e encapsulamento, obrigatórios na vida de um profissional de desenvolvimento, são conhecimentos comumente encontrados de forma rasa. As faculdades fazem o papel apenas de fomentar e ensinam a parte teórica, uma aplicação básica, projetos simples, mas sem muito rigor sobre o uso correto dessas ideias. Assim, o entendimento propriamente dito, vem apenas(quando vem) com a experiência, no dia-a-dia profissional.

Não é fácil encontrar sistemas se beneficiando com as boas práticas da programação orientada a objetos, muito pelo contrário, é muito mais comum encontrar aberrações que contradizem conceitos de código limpo, como por exemplo: classes com mais de 10.000 linhas tratando de múltiplos assuntos, com funções que fazem mil e uma coisas.  É importante dizer que essas falhas não são inerentes a programadores de uma ou outra linguagem, muito pelo contrário, já vi muito lixo escrito em php, python, java e c#, por exemplo.

Antes de começar a estudar sobre Programação Orientada à Objetos algumas das perguntas mais frequentes são: por que usar? Quais as vantagens de se ter baixo acoplamento, alta coesão e forte acoplamento? De imediato posso dizer que alguns benefícios são bem populares e desejáveis, como: código limpo, testável, mínimo de complexidade, reaproveitamento e fácil manutenção. No entanto, nenhum desses benefícios convence caso o entendimento conceitual não esteja bem claro.

A definição desses conceitos de forma direta e simples

Acoplamento

Trata do quanto uma classe é dependente de outra. Sendo assim, quando menor acomplamento melhor. Quanto mais forte o acoplamento, mais efeito cascata, ou seja, mais difícil é de se reaproveitar o código, já que uma alteração numa classe força alterações em outras.

Testes unitários é uma prática que ajuda a manter o baixo acomplamento, já que o objetivo é testar a unidade de código, ou seja, o método. Uma classe com forte acomplamento é praticamente impossível de ser testada.

A prática de herança, embora muito popular em POO, deve ser usada com muita análise e moderação, pois seu efeito é contrário: gera acoplamento. Analise a possibilidade de usar Interfaces, ao invés de herança.

Coesão

Em redação, coesão nada mais é que a ligação harmoniosa entre os parágrafos, fazendo com que fiquem ajustados entre si, mantendo uma relação de significância. Em desenvolvimento de software não é muito diferente. A definição mais comum diz que uma classe deve ser responsável por um único assunto.

É a exatamente isso que se refere o S do SOLID, que fala do princípio de responsabilidade única.

Encapsulamento

De acordo com o Aurélio, encapsular é encerrar em cápsula. Em programação significa organizar, ou separar por partes, tornando possível controlar o acesso a propriedades e métodos. Na prática é como guardar todas as funcionalidades dentro de uma caixa organizadas segundo algum critério e disponibilizá-la através de uma interface.

Como se aprofundar

Para nossa sorte, vários outros profissionais já haviam se indignado com problemas de códigos mal escritos, com forte acoplamento, baixa coesão, encapsulamento sem sentido, entre outros problemas. Em meados da década de 1990, Robert C. Martin escreveu os princípios básicos de programação e design orientados a objetos. É justamente o que conhecemos como S.O.L.I.D.

Visão geral sobre S.O.L.I.D.

S(single responsibility principle)
Princípio de responsabilidade única. Uma classe deve ter apenas uma responsabilidade. O mundo já seria lindo se apenas este princípio fosse seguido.

O(open/closed principle)
Entidades devem ser abertas para extensões e fechadas para modificações.

L(Liskov substitution principle)
Conhecido como o princípio de substituição de Liskov. Foi criado por Barbara Liskov e diz o seguinte: Classes derivadas devem ser substituíveis por suas classes base.

I(interface segregation principle)
Em português, o princípio de segregação de interface. Deve-se usar interfaces específicas e não interface única.

D(dependency inversion principle)
Princípio de inversão de dependência. Significa que a classe deve depender de abstração e não de implementação.

As consequências de estudar e praticar tais princípios é se tornar um profissional mais aprimorado, escrever códigos de qualidade e, consequentemente, desenvolver software com excelência.

Quem quiser se aprofundar no assunto, seguem algumas dicas de livros:

Questões, críticas construtivas e sugestões são bem vindas.