Princípios do SOLID

Desde a década de 1980, Robert C. Martin (Uncle Bob) buscou reunir um conjunto de princípios que orientasse como organizar as funções e estruturas de dados dentro de um sistema de software. No ano de 2000, o tal conjunto de princípios teve sua versão final apresentada, mas apenas em 2004 Michael Feathers reorganizou os princípios com a inicial de cada nome e formou o acrônimo SOLID.

A princípio seguir um conjunto de regras na hora do desenvolvimento de um software parece ser algo chato, principalmente no inicio da carreira de um desenvolvedor, mas são extremamente necessárias quando se trata de grandes projetos e o código é compartilhado por uma equipe de desenvolvedores. Aumento de produtividade, diminuir a duplicação de código e estender o projeto sem que cause grande impactos são alguns dos objetivos do conjunto de princípios que darei uma breve introdução nesse artigo.

SRP (Single Responsibility Principle)

O primeiro princípio do acrônimo se trata da responsabilidade única, e está diretamente ligado com a coesão de uma classe. E do que se trata coesão em um paradigma orientado a objeto? O nível de coesão de uma classe se mede pelas responsabilidades e propósitos, uma classe com baixa coesão tem muitas responsabilidades e não tem um propósito definido. E é esse o principal ponto do princípio.

“Um módulo deve ter uma, e apenas uma, razão para mudar”.

Uma classe deve ter apenas uma responsabilidade, uma razão para que seja alterada. Classes com muitas responsabilidades se tornam confusas, de difícil entendimento e complexa para dar manutenção. Então quando detectar que uma classe faz mais do que seu propósito, significa que suas responsabilidades devem ser revistas e divididas em novas classes.

OCP (Open-Close Principle)

Sempre que fizer uma implementação em um software, a nova implementação deve ser feita sem que se altere o que já foi feito. Essa é uma breve explicação para a segundo princípio, o princípio do Aberto-Fechado. Ele diz que:

“O código deve ser ABERTO para extensão, mas FECHADO para alteração”.

A alteração de um código implica em mudar o que já está pronto, alterações causam impactos em um software e devem ser evitadas para que bugs não sejam criados. A estruturação de um código para que seja estendido torna o software flexível, fácil de dar manutenção e poucos impactos nas mudanças.

LSP (Liskov Substituition Principle)

“Se parece como um pato, grasna como um pato, mas precisa de bateria, provavelmente você está utilizando a abstração de forma incorreta”.

Essa é uma das analogias muito utilizadas para explicar o princípio de substituição de Liskov. Em 1988 Barbara Liskov criou o que vem a ser hoje o terceiro princípio do SOLID, de modo resumido o princípio diz que classes derivadas devem ser substituíveis por suas classes bases, porém esse princípio pode ser facilmente infringido a partir do momento que a classe derivada altera o comportamento da classe base.

ISP (Interface Segregation Principle)

A segregação de interface, o quarto princípio do SOLID, vem a ser um dos princípios mais simples e fácil de ser compreendido, mas também um dos que mais sofre violação.

“Clientes não devem ser forçados a depender de interface que eles não usam.”

Uma classe não deve importar uma interface na qual contenha mais elementos do que irá utilizar. O quarto princípio prega a utilização de interfaces específicas e reduzir interfaces genéricas.

DIP (Dependency Inversion Principle)

O quinto e último elemento do SOLID se trata de um dos pilares da arquitetura de software, o princípio da inversão de dependência diz que:

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

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

De maneira simples e resumida, uma classe não deve se referir a itens concretos e sim a interfaces, classes abstratas ou qualquer outro tipo de abstração, de modo que diminua o acoplamento da classe. Módulos com alto acoplamento faz com que o software se torne difícil de ser alterado, e as alterações podem afetar outros módulos do software.

Conclusão sobre os princípios do SOLID

Como pode-se observar, seguir os princípios do SOLID vem a ser uma ótima alternativa para melhorar a estrutura dos módulos dentro de um projeto, diminuindo o acoplamento, tendo maior reaproveitamento de código, menor complexibilidade, maior coesão, fazer com que novas implementações e alterações não cause danos em outros módulos e principalmente tornar o projeto manutenível, estendendo assim o seu tempo de vida.

Este artigo teve como principal objetivo trazer uma breve introdução dos princípios reunidos por Robert C. Martin, apresentar suas regras e seus benefícios dentro de um projeto. Em artigos futuros, conheceremos mais a fundo cada um dos princípios, trazendo exemplos de erros comuns no dia a dia de um desenvolvedor e aplicando os princípios para o melhor entendimento de como funciona e sua importância.