O objetivo deste artigo é literalmente descomplicar um dos princípios SOLID de forma fácil e rápida. Esse artigo é inspirado em situações e dificuldades reais já vivenciadas que me fez ter uma visão um pouco mais abrangente sobre o uso dos princípios SOLID e como eles podem ser úteis no desenvolvimento.
Resolvi escrever esse artigo porque esse é um tema que eu gosto muito, e também porque percebi que muitas pessoas tem dúvidas sobre como e quando utilizar. Espero ajudar de alguma forma essas pessoas e sanar suas dúvidas.
Além do mais, neste artigo, irei focar em apenas um princípio a fim de não ficar tão extensa e cansativa a leitura. Porém, iremos entender sobre o que de fato é o SOLID e como e quando utilizar o primeiro princípio.
Então, vamos começar?
O que é SOLID?
SOLID são cinco princípios da programação orientada a objetos que facilitam no desenvolvimento de softwares, tornando-os fáceis de manter e estender. Esses princípios podem ser aplicados a qualquer linguagem de POO.
Bons sistemas de software começam com um código limpo, já dizia Robert C. Martin em seu livro "Arquitetura limpa: O guia do artesão para estrutura e design de software". Se por um lado os tijolos não são bem-feitos, isso compromete a construção da arquitetura. Por outro lado, você pode fazer uma bagunça considerável com tijolos bem-feitos. É aí que entram os princípios SOLID. De forma resumida, SOLID nos dizem como organizar funções e estruturas de dados em classes e como essas classes devem ser interconectadas.
Os 5 princípios(S.O.L.I.D)
SRP: Princípio da Responsabilidade Única (Single Responsibility Principle)
OCP: Princípio do Aberto/Fechado (Open-Closed Principle)
LSP: Princípio de Substituição de Liskov (Liskob Substitution Principle)
ISP: Princípio da Segregação de Interface (Interface Segregation Principle)
DIP: Princípio da Inversão de Dependência (Dependency Inversion Principle)
O Princípio da Responsabilidade Única
"A melhor estrutura para um sistema de software deve ser altamente influenciada pela estrutura social da organização que o utiliza, de modo que cada módulo de software tenha uma, e apenas uma, razão para mudar." - Robert C. Martin
Provavelmente você já pode ter ouvido a famosa frase: "Faça uma coisa só, mas a faça bem feita", né? Esse primeiro princípio quer dizer exatamente isso.
Quando um sistema tem responsabilidades bem definidas e acopladas de maneiras separadas isso gera um desenvolvimento mais limpo e melhor definido, além de outros benefícios como menor acoplamento e organização.
Nesse exemplo acima, o que você ver de errado? Sim, isso mesmo: uma única classe tem várias responsabilidades. Isso poderá gerar um alto acoplamento, pois mais responsabilidades geram um maior nível de dependências, deixando o sistema engessado e frágil para alterações.
Agora vamos seguir o que o princípio da responsabilidade única sugere, que é cada uma das classes que contém uma família de métodos é um escopo. Sendo assim cada classe terá seu "papel", fazendo apenas o que é sua responsabilidade:
Considerações finais
Aplicar o princípio da responsabilidade única, é importante para uma arquitetura madura e sustentável. Quando começamos a dar valor a princípios como este, vemos que estamos amadurecendo e fazendo melhor o que gostamos de fazer: software.
Esse foi o primeiro artigo de uma série de cinco. Eu gostei muito de trazer esse tema e poder explicar utilizando explicações claras e acessíveis. Nos próximos dias estarei escrevendo o próximo artigo, na qual falaremos sobre o OCP: Princípio do Aberto/Fechado (Open-Closed Principle).
Obrigada por ler até aqui, espero que eu tenha colaborado com o seu conhecimento. Até breve!
Referências
devmedia.com.br/arquitetura-o-principio-da-..
javatpoint.com/solid-principles-java
Arquitetura Limpa de Robert C. Martin