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, 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.
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.
Top comments (0)