Autor dos Princípios SOLID
Criado por Robert Cecil Martin, coloquialmente chamado de "Uncle Bob", ele é um engenheiro de software, treinador e autor de best-sellers americano. Ele é mais conhecido por desenvolver muitos princípios de design de software e por ser o fundador do influente Manifesto Ágil.
Sigla SOLID
“S” se refere a Single Responsibility Principle (Princípio da Responsabilidade Única),
“O” diz respeito a Open-Closed Principle (Princípio de Aberto-Fechado),
"L” corresponde ao termo Liskov Substitution Principle (Princípio da Substituição de Liskov),
“I” remete ao termo Interface Segregation Principle (Princípio da Segregação de Interface),
“D” é referente a Dependency Inversion Principle (Princípio da Inversão de Dependência).
S - Princípio da Responsabilidade Única (SRP)
O Princípio da Responsabilidade Única diz que “Uma classe deve ter somente uma única razão para ser alterada, ou em outras palavras, uma classe deve possuir responsabilidade única”.
O princípio pode ser aplicado a funções também. Mas afinal, o que é uma responsabilidade e como saber se uma classe ou função possui ou não somente uma?
Uma responsabilidade pode ser considerada como um papel que uma classe ou função é responsável por executar, mas uma melhor definição, quando se tratando desse princípio, seria que uma responsabilidade é, basicamente, uma razão para mudar.
S - Princípio da Responsabilidade Única (SRP)
O exemplo a seguir é de uma classe chamada "Car" que deveria representar o modelo de carro mas possui alguns serviços também. Nesse caso é melhor separar as classes. Classes e funções que respeitam o princípio da responsabilidade única são mais legíveis e testáveis
O - Princípio Aberto-Fechado (OCP)
O Princípio do Aberto-Fechado diz que “Entidades de software (classes, módulos, funções, etc) devem ser abertos para extensão, porém fechados para modificação”.
Por vezes, estendemos as funcionalidades de nossas entidades e como estas estão acopladas a outras entidades acabamos tendo que efetuar modificações.
O - Princípio Aberto-Fechado (OCP)
Um exemplo disso é quando temos uma estrutura de "switch case" que para cada tipo efetuamos um chamada da classe recebida. A cada nova classe e implementação precisamos adicionar um novo case. Isso infringe o princípio.
Podemos resolver isso implementando um protocolo/interface para essas classes para garantir que todas tenham o método a ser chamado na estrutura de switch. Dessa forma não precisamos mais usar a estrutura de switch e modificá-la sempre que um novo tipo de classe for adicionado.
L - Princípio de Substituição de Liskov (LSP)
A definição matemática original, de Barbara Liskov para esse princípio é Se para cada objeto o1 de tipo S, existe um objeto o2 de tipo T, de modo que para todos programas P definidos em termos de T, o comportamento de P é inalterado quando o1 é substituído por o2 , então S é um subtipo de T.
HAM???
Vou tentar explicar de uma forma melhor: O princípio define que os objetos de uma superclasse devem ser substituídos por objetos de suas subclasses sem quebrar a aplicação. Classes filhas nunca deveriam infringir as definições de tipo da classe pai.
L - Princípio de Substituição de Liskov (LSP)
No exemplo, podemos ver que o motorista consegue dirigir o veículo sem saber o tipo de veículo, somente sabendo as funções básicas.
I - Princípio de Segregação de Interface (ISP)
Como o nome sugere, esse princípio diz que devemos segregar as interfaces, ou seja, separá-las em várias.
Um termo usado por Uncle Bob, que nos ajudará a tornar as coisas mais claras, é “Fat Interfaces”. Traduzindo ao pé da letra, interfaces gordas. Esse tipo de interface gera alguns problemas, como refatoração desnecessária e necessidade de recompilar e retestar quando mudanças são necessárias.
Isso acontece porque esse tipo de interface acaba gerando acoplamentos desnecessários e, quando uma mudança em uma interface gorda é necessária, todas as classes que a implementam terão que ser compiladas e testadas novamente.
I - Princípio de Segregação de Interface (ISP)
No caso abaixo, vemos que nem todas as aves sabem voar e por isso o ideal é criar tipos mais específicos e aplicá-los separadamente.
D - O princípio de inversão de dependência (DIP)
Neste caso, temos um serviço diretamente dependente da classe HttpClient, criando acoplamento com a lib do axios.
D - O princípio de inversão de dependência (DIP)
A melhor forma nesse caso é implementar uma injeção de dependência por meio de uma interface para desacoplar a classe HttpClient.
Abílio Azevedo
https://www.linkedin.com/in/abilioazevedo/
https://abilioazevedo.com.br
me@abilioazevedo.com.br
Obrigado!
Fontes
https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-in-pictures-b34ce2f1e898
https://www.youtube.com/watch?v=6SfrO3D4dHM
https://imasters.com.br/back-end/solid-com-php
https://medium.com/desenvolvendo-com-paixao/o-que-%C3%A9-solid-o-guia-completo-para-voc%C3%AA-entender-os-5-princ%C3%ADpios-da-poo-2b937b3fc530
Saiba mais