Antes de iniciarmos o papo sobre esse princípio, vamos primeiro entender qual problema queremos resolver.
Alguns anos atrás, quando comecei a estudar programação, me lembro que tinha apenas um objetivo quando parava para codar algo. Basicamente a minha preocupação era em fazer o que me foi pedido funcionar.
Bom, mas o mundo vem mudando, de forma exponencial.
Pense bem, a Blockbuster foi fundada em 1985, e atingiu seu auge por volta de 1995, declarando falência em 2011.Ou seja, em aproximadamente 10 anos, saímos do alto consumo de DVDs, para Streaming.
O que nos mostra que o grande poder de um negócio, é o mesmo que trouxe a humanidade até aqui. O poder de adaptação e evolução rápida.
Bom, como hoje a maior parte das coisas são digitais, e a tendencia é que o mercado se torne cada vez mais tecnológico, fica claro que apenas atender a um pedido não é mais o suficiente, nossos sistemas precisam ser mais, precisam ser adaptáveis e reutilizáveis. Não podemos nos dar ao luxo de construir tudo do zero cada vez que algo muda, principalmente porque assim que você terminar de construir possivelmente isso já mudou.
Pois bem, dado esse rápido panorama de evolução, o princípio SOLID traz vários benefícios, mas tem um principal objetivo. Transformar seu código em algo adaptável e prolongar a vida dele.
Agora vamos aos significados de cada letra dessas.
S – Single Responsibility
Como o nome já diz, esse é o princípio de responsabilidade única, que na minha opinião é um dos mais difíceis de ser alcançado.
De forma geral a ideia é que uma classe, função ou método tenha apenas uma responsabilidade bem definida e não ultrapasse o limite desta responsabilidade.
Entenda que sua função deve tratar um e apenas um assunto, pois caso ela trate muitos assuntos ela pode e vai trazer problemas futuros.
Pense bem em como começamos esse texto, tudo se resume no poder de adaptação, e no caso de uma função com diversas responsabilidades, em alterações futuras fica difícil identificar e altera-la sem impactar as demais.
Ou seja, não te ajuda se você quer que essa classe tenha desacoplamento máximo do restante do código.
Mas qual a dificuldade?
Assim como em microsserviços, definir a “responsabilidade” de uma função é algo conceitual e difícil. Até onde ir? Qual a granularidade ideal de uma “responsabilidade” única.
Dica: Existem métricas de números de linhas ou de ações que ajudam a saber se sua classe está muito grande ou muito pequena, isso pode te ajudar.
O – Open-Closed
Esse princípio normalmente é o mais quebrado no dia a dia.
A ideia aqui é que seu objeto ou entidade fiquem Open para extensão, ou seja, conforme venham novas necessidades a ideia é que o código aumente. Em contra partida, eles devem ficar Close para modificação. Ou seja, o que mais vemos no dia a dia, aquela alteração simples no código, mudando algo que já existia, não deveria ocorrer.
Mas por que? É bem mais rápido e fácil simplesmente alterar.
É, se pensar apenas na codificação é algo a ser discutido, mas se analisarmos o todo, estamos basicamente alterando algo que já funcionava, trazendo um risco desnecessário, e possivelmente aumentando nosso esforço de testes. Ou seja, perdemos não na alteração, mas em tudo que vem depois dela. E vamos ser honestos, a maior parte das vezes não é tão simples como imaginávamos na primeira alteração.
L – Liskov Substitution
Conceito criado no mesmo ano de nascimento deste que vos fala, em 1987, sim não é nenhum jovenzinho, mas traz uma proposta bastante importante.
“Classes derivadas devem poder ser substituídas por suas classes bases”
Agora sim, ficou fácil, deu pra entender tudo, rs.
Vamos lá, olhando apenas pela descrição, não parece fazer muito sentido, por esse motivo vou começar explicando o propósito desse princípio.
Ele basicamente te mostra quando uma classe filha não parece fazer sentido para uma classe pai, ou seja, quando isso acontece você deveria repensar a forma de implementação para não quebrar esse princípio.
Imagine que você tenha uma classe estendida de uma classe base, você precisa conseguir substituir essa classe pela classe base. Na implementação imagine você com uma classe derivada instanciada a uma classe base, caso o retorno quebre a aplicação, significa que você está infringindo o conceito.
I – Interface Segregation
“Uma classe não deve ser forçada a implementar interfaces e métodos que não irá utilizar”
Outro princípio que te ajuda a pensar se a implementação está fazendo sentido.
Imagine que você possui uma interface declarada que não está abstrata o suficiente, ao ser utilizada em uma classe pode ser que alguns métodos não façam sentido, e se isso acontecer é necessário reavaliar o conceito.
Um exemplo básico para entender.
Imagine que você tenha uma interface chamada mamífero.
Podemos dizer que mamíferos fazem duas coisas.
1 – Beber leite
2 – Andar
Ao implementar isso em uma classe Cavalo, tudo certo, cavalos bebem leite e andam.
Agora se a classe for Golfinho, já não funcionou né? Bom esse é um exemplo que sua interface não está da melhor maneira.
Exemplo horrível, mas foi o que eu consegui pensar…rs
D – Dependency Inversion
“Dependa de abstrações e não e implementações”
Quando olhamos para uma implementação, ou trecho de código já escrito, e criamos uma dependência dela, acabamos por criar acoplamento, que é algo que não queremos. Já quando falamos de uma abstração, temos algo mais alto nível que tende a não causar dependência, diminuindo o acoplamento.
Bom, acabaram-se as letras do SOLID e com elas o conceito que queria apresentar para vocês, busquei trazer de forma simples e direta. Espero ter conseguido ajudar no entendimento desse conceito.
Lembrem-se, a ideia principal por trás da utilização deste princípio, é a de desacoplar e trazer facilidade para futuras implementações e mudanças, no seu código e no seu negócio.
Aqui vai uma dica de livro sobre o tema :
Curtiu? Compartilhe esse conteúdo com seus amigos e equipe.
Quer ver ainda mais dicas de tecnologia? Me siga nas redes sociais.
Deixe uma resposta