O SOLID é um facilitador que torna o código mais coeso, além de mais fácil de manter, estender, adaptar e ajustar conforme alterações de escopo. Além disso, ele faz com que o código seja testável e de fácil entendimento, extensível e forneça o máximo de reaproveitamento.

Neste artigo, vamos entender tudo sobre o que é SOLID e como você pode aplicá-lo. Vamos nessa?

O que é SOLID?

SOLID é um acrônimo para cinco postulados de design de código em POO (Programação Orientada a Objeto), utilizados para facilitar a compreensão, o desenvolvimento e a manutenção de software.

Estes postulados, apresentados por Robert C. Martin (conhecido como Uncle Bob), em um artigo em 2000, foram posteriormente unidos neste termo muito utilizado hoje em dia na área de programação por Michael Feathers: SOLID.

Quais são esses princípios do SOLID?

Os cinco princípios apresentados por Uncle Bob são:

• Single Responsability Principle (Princípio da Responsabilidade Única);
• Open/Closed Principle (Princípio Aberto/Fechado);
• Liskov Substitution Principle (Princípio da substituição de Liskov);
• Interface Segregation Principle (Princípio da Segregação de Interface);
• Dependency Inversion Principle (Princípio da Inversão de Dependência).

O que significa cada um?

Single Responsability Principle

“Uma classe deve ter um, e somente um, motivo para mudar”.

Esse princípio nos diz que cada classe dentro de um projeto deve se especializar em um único assunto e possuir uma única responsabilidade, tendo uma única tarefa ou ação para executar.

Muitas vezes, ao criar uma classe, damos a ela muitas responsabilidades, mesmo aquelas que a classe não utilizará. Ainda que pareça útil no primeiro momento, caso o programa necessite alguma alteração devido à atualização de bibliotecas ou simplesmente alguma alteração requerida pelo cliente, dificilmente teremos um resultado positivo. Isso porque, com as responsabilidades misturadas dentro da classe, temos a chance de comprometer àquelas que não necessitam alteração.

Dessa forma, ao utilizar o S do SOLID, estamos garantindo que cada classe cuidará apenas das responsabilidades necessárias para que ela funcione. Assim, não será necessário alterar todas as implementações dela em caso de alterações futuras.

Open/Closed Principle

“Objetos ou entidades devem estar abertos para extensão, mas fechados para modificação”.

Conforme o software é desenvolvido, mais recursos vão sendo necessários para que a aplicação funcione como esperado.

Esse princípio nos diz que, ao criar um objeto ou entidade, devemos prepará-lo para que possa ser implementado por outro futuramente. Assim, não será necessário modificar o objeto pai.

Dessa forma, conseguiremos manter nossos objetos desacoplados de outros, podendo futuramente alterar bibliotecas e frameworks, ou até mesmo adicionar novas funções apenas criando uma classe implementando o objeto original.

Liskov Substitution Principle

“Uma classe derivada deve ser substituível por sua classe base”

Apresentado por Barbara Liskov em 1987, em sua conferência “Data abstraction”, o princípio, de forma simplificada diz: “se S é um subtipo de T, então os objetos do tipo T, em um programa, podem ser substituídos pelos objetos de tipo S sem que seja necessário alterar as propriedades deste programa.”

Sendo mais direto, esse princípio nos diz que, se uma função necessita de uma classe que está sendo implementada por outras, podemos utilizar tanto a classe base quanto as classes que são derivadas desta primeira. Isso porque todas seguem os mesmos padrões, alterando apenas as implementações da original.

Este princípio nos garante o desacoplamento dos nossos objetos, possibilitando uma melhor manutenção e atualização do nosso código quando necessário.

Interface Segregation Principle

“Uma classe não deve ser forçada a implementar interfaces e métodos que não utilizará”

Esse princípio mostra que devemos criar interfaces mais específicas para nossos objetos, ao invés de uma classe mais genérica para todos do mesmo tipo.

Dessa forma, conseguiremos dar mais segurança às classes criadas em nossos programas. Isso porque, com interfaces mais específicas, colocamos apenas os atributos e as funções que aquela classe que a implementação utilizará.

Dependency Inversion Principle

“Dependa de abstrações e não de implementações”

Sobre esse princípio, Uncle Bob nos confere duas definições:

1. “Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender da abstração”;
2. “Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações”.

Com a Inversão de Dependência, conseguimos desacoplar nossas classes de bibliotecas específicas e fazer com que outras ferramentas possam ser utilizadas no lugar desta primeira. Assim, as classes utilizarão abstrações de interfaces ao invés de outras classes ou de instâncias objetos. 

Conclusão

Neste artigo, vimos o que é SOLID e como ele pode facilitar a vida de muitos desenvolvedores.

Em POO, dizemos que a programação deve ser realizada para interface e não para uma implementação. Por isso, sempre devemos criar uma interface que nos diz o que aquela entidade irá realizar.

Então, conseguimos manter nossa arquitetura de código limpo, podendo construir aplicações com uma boa manutenção conforme o tempo. Permitindo que, caso necessário, possamos alterar ferramentas e bibliotecas sem problemas de corromper o restante do código.

Veja também:

Aprenda o que é Unix!