SOLID: O conceito por trás do código
Tags: solid, braziliandevs, architecture, tutorial
Published: 2022-05-15 22:08:56

Muitas empresas pedem em suas posições de desenvolvimento que os profissionais tenham conhecimento de SOLID. No entanto, muitos acreditam que é apenas um conjunto de práticas durante o desenvolvimento, mas não conhecendo de fato a teoria por trás. 

Os princípios S.O.L.I.D., um acrônimo com as iniciais dos princípios abordados a seguir, tem como finalidade organizar as funções e estruturas de dados de forma a facilitar o desenvolvimento e evolução de software. O objetivo desses princípios é criar códigos que tolerem mudanças, sejam fáceis de entender e que sejam a base de componentes que possam ser usados em diversos sistemas. 

**S - Single Responsiblity Principle** (SRP, ou Princípio da Responsabilidade Única em português)
**O - Open-Closed Principle** (OCP, ou Princípio Aberto-Fechado em português)
**L - Liskov Substitution Principle** (LSP, ou Princípio da substituição de Liskov em português)
**I - Interface Segregation Principle** (ISP, ou Princípio da Segregação da Interface em português)
**D - Dependency Inversion Principle** (DIP, ou Princípio da inversão da dependência em português)

A seguir será detalhado cada um desses princípios acima.


### SRP: O Princípio da Responsabilidade Única

Esse princípio mostra que uma classe deve ser especializada em um único assunto e ter apenas uma responsabilidade. Em outras palavras, a classe deve ter uma única ação para executar. 

MARTIN (2017) reformula a descrição comumente usada, de que um módulo deve ter apenas uma razão para mudar, e disserta que o SRP deve ser descrito como um módulo que deve ser responsável por apenas um ator. Esse ator é a representação de um usuário ou stakeholder que são a ”razão para mudar” da definição inicial. O termo módulo pode ser definido como o arquivo-fonte ou um conjunto coeso de funções e estrutura de dados. 

**A violação desse princípio pode fazer com que uma classe assuma responsabilidades que não são suas**, aumentar o nível de acoplamento, gerar dificuldades na implementação de testes automatizados e tornar difícil o reaproveitamento do código.

### OCP: O Princípio Aberto/Fechado

Esse princípio foi criado por Bertrand MEYER (1997) e afirma que um software deve ser aberto para extensão, mas fechado para modificação. Ou seja, quando novos recursos precisam ser adicionados no sistema ele deve ser estendido e não alterar o código fonte original.

Segundo MARTIN (2017), o OCP é uma das forças motrizes na arquitetura de sistemas, sendo este princípio o mais importante da orientação a objetos. Para que seja possível cumprir com o objetivo de o sistema ser fácil sem que essa mudança cause um impacto grande é preciso dividir o sistemas em componentes. Esses componentes são organizados em uma hierarquia de dependências, de forma a proteger os componentes de alto nível das mudanças realizadas em componentes de níveis inferiores.

### LSP: O Princípio de Substituição de Liskov

O Princípio da Substituição de Liskov foi definido por Barbara Liskov e disserta sobre usar como base a propriedade de substituição. Essa propriedade é descrita pela demonstração: 

> se, para cada objeto o1 de tipo S, houver um objeto o2 de tipo T, de modo que, para todos os programas P definidos em termos de T, o comportamento de P não seja modificado quando o1 for substituído por o2, então S é um subtipo de T. (MEYER, 1997).

Em outras palavras, o LSP diz que 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 a necessidade de alterar as propriedades desse sistema. 

O LSP se transformou em um princípio mais amplo de padrão de projeto, podendo ser aplicado em interfaces e implementações. Esse princípio nos diz que as implementações devem obedecer a algum tipo de contrato. A aplicação do LSP é importante, pois os usuários precisam de interfaces bem definidas e dessa capacidade de substituição de implementação das interfaces. Esse princípio deve ser aplicado à arquitetura, dado que uma violação na capacidade de substituição pode contaminar a arquitetura do sistema com uma grande quantidade de mecanismos extras (MARTIN, 2017). Alguns exemplos do que pode acontecer ao violar esse princípio são:
* lançar uma exceção inesperada;
* sobrescrever ou implementar um método que não faz nada;
* retornar valores de tipos diferentes da classe base.

### ISP: O Princípio da Segregação de Interface

Esse princípio mostra que uma classe não deve ser forçada a implementar interfaces e métodos que não vá utilizar, ou seja, é melhor criar interfaces mais específicas do que ter uma grande interface genérica. As classes não devem depender de coisas de que não precisam.

Utiliza-se esse princípio na arquitetura para evitar que existam dependências de módulos com muitos elementos desnecessários. Isso é válido tanto em níveis arquiteturais mais altos quanto mais baixos, como por exemplo as dependências de código fonte podem forçar de forma desnecessária a recompilação e reimplantação.

### DIP: O Princípio da Inversão de Dependências

Sobre o Princípio de Inversão de Dependências, MARTIN (2017) expõe que os sistemas mais flexíveis são aqueles nos quais as dependências de código-fonte se referem apenas a abstrações e não a itens concretos. 

No geral, fala que nenhuma classe ou função deve se preocupar com a forma como uma determinada coisa é feita. Algumas classes, como por exemplo a classe String, são concretas, então não seria interessante forçá-las a ser abstratas. Entretanto, essas classes são muito estáveis de forma que as mudanças nelas são muito raras e controladas, logo não é necessário se preocupar com essas mudanças. Classes concretas são toleráveis pois sabe-se que elas não irão mudar.

Aplicando à [Arquitetura Limpa](https://dev.to/rubemfsv/arquitetura-limpa-o-conceito-por-tras-do-codigo-4kdf), os módulos de alto nível não devem depender de módulos de baixo nível, os dois devem depender da abstração. As abstrações não devem depender de detalhes e sim os detalhes que devem depender das abstrações.


## Conclusão

SOLID não é apenas mais uma linha nos requisitos das empresas ao buscar por profissionais, é um conjunto essencial de boas práticas. 

Quando esses princípios são aplicados nos sistemas, eles tendem a ser mais bem estruturados, coesos e que escalam de maneira mais harmônica - sendo eles fundamentais para a [Arquitetura Limpa](https://dev.to/rubemfsv/arquitetura-limpa-o-conceito-por-tras-do-codigo-4kdf).

**Todo** bom profissional deve buscar se aprofundar nos princípios SOLID, aplicá-los em seu dia a dia e disseminá-los em seus times. Boas práticas devem ser difundidas e aplicadas.


## Referências

* MARTIN, Robert C. Clean Architecture: A Craftsman’s Guide to Software Structure and Design. 1st. ed. USA: Prentice Hall Press, 2017. ISBN 0134494164.
* MEYER, Bertrand. Object-Oriented Software Construction. 2. ed. Upper Saddle River, NJ: Prentice Hall, 1997. ISBN 978-0-13-629155-8.