O que é SOLID?
O SOLID é um conjunto de 5 princípios que ajudam os programadores a escreverem um software mais fácil de entender, mudar e manter. Esses princípios foram criados para ajudar os desenvolvedores a escreverem códigos mais organizados e estruturados, o que facilita o processo de desenvolvimento de novas funcionalidades e correções de bugs 🚀
SOLID , um conceito muito difundido na programação orientada a objetos, pode ser usada em programação funcional? vamos ver o que o Uncle Bob tem a dizer sobre isso:
Tweet traduzido de: https://twitter.com/unclebobmartin/status/1164511654618550273
Quais são os conceitos Solid?
S: Single Responsibility Principle
O: Open–closed principle
L: Liskov substitution principle
I: Interface Segregation Principle (Princípio da Segregação da Interface)
D: Dependency Inversion Principle
Single Responsibility Principle:
“Um Componente ou função só deve fazer uma coisa e fazê-la direito. “
Ao separar as responsabilidades de cada componente, torna-se mais fácil testar, depurar e modificar o código sem afetar outras partes do sistema. Quando as funções ou classes são sobrecarregadas com muitas responsabilidades, torna-se difícil entender e modificar o código com segurança, pois as mudanças em uma parte do código podem afetar inesperadamente outras partes. Além disso, quando uma função tem apenas uma responsabilidade clara, é mais fácil de ser reutilizada em diferentes partes do sistema, o que pode ajudar a evitar a duplicação de código.
Aqui um componente de listagem de ursos:
Qual o problema com esse componente? Vamos lá:
- Ele faz uma chamada de API
- Filtra os dados desta chamada
- Renderiza os resultados em uma lista HTML.
Como resolver os problemas definidos no slide anterior respeitando o princípio de Single Responsibility?
Para respeitar o princípio de Single Responsibility, podemos separar cada parte desse componente em funções separadas. Dessa forma, cada função teria uma única responsabilidade e seria mais fácil de manter e testar. Além disso, podemos criar hooks personalizados para lidar com cada parte desse componente e organizar melhor o nosso código.
No final, teríamos um componente final que apenas chamaria as funções necessárias e renderizaria a lista de resultados.
Open Closed Principle no React/TS
“Robert C. Martin (Uncle Bob) considerou este princípio como o‘ princípio mais importante do design orientado a objetos ’. Mas ele não foi o primeiro a defini-lo. Bertrand Meyer escreveu sobre isso em 1988 em seu livro Object-Oriented Software Construction.
Ele explicou o princípio Open/Closed como: ‘Entidades de software (classes, módulos, funções, etc.) devem ser abertas para extensão, mas fechadas para modificação.’
A primeira versão do código não segue este princípio, pois modifica o código original para adicionar novas funcionalidades.
A segunda versão do código segue o princípio aberto-fechado, pois utiliza condições para estender o componente sem modificar o código original.
Liskov Substitution Principle no React/TS
O princípio de Liskov Substitution nos diz que:
“Os componentes devem obedecer a algum tipo de contrato.”
Basicamente, isso significa que deve haver algum tipo de contrato entre os componentes. Portanto, sempre que um componente usa outro componente, ele não deve interromper sua funcionalidade (ou criar algum efeito colateral indesejado).
Podemos usar o exemplo de listagem de ursos:
O componente BearScreen vai chamar o Search passando algumas propriedades, mas utilizando o primeiro exemplo de Search, não a garantia de como é esperado essas propriedades podendo receber um undefined em handleSearchTermChange ou um searchTerm capaz de quebrar o value.
index.jsx
Eis que pode se estourar um erro no console
Então TypeScript vem para nos salvar! Quando tiramos as propriedades do nosso componente estamos atribuindo a ele um tipo único que caso não seja obedecido, vai estourar um erro no nosso Vs Code:
index.tsx
Dica: Uma opção também é utilizar Proptypes
Interface Segregation Principle
No React/TS O princípio de Interface Segregation nos diz que: “Os componentes não devem depender de coisas de que não precisam.”
Imagine que temos nosso componente de ursos pai, que renderiza um Componente com detalhes do urso, e um com imagens do urso, e em ambos passamos nosso objeto bear:
Qual o problema com o código da imagem anterior?
1 – Ele está passando props desnecessárias para nossos componentes filhos, esse tipo de situação é muito comum quando retornamos a resposta de uma API sem tratar os dados devidos, ou não tipos e passamos os parâmetros certos para nossos componentes
2- Basta passar o objeto correto para nossos componentes filhos e então não violamos mais o princípio de Interface Segregation.
Dependency Inversion Principle
No React/TS O princípio de Dependency Inversion nos diz que: “Nenhum componente ou função deve se preocupar com a forma como uma determinada coisa é feita.”
Basicamente, em vez de depender de implementações concretas, os componentes devem depender de abstrações (interfaces ou classes abstratas) que possam ser substituídas por outras implementações sem afetar o comportamento do sistema.
No exemplo abaixo qualquer mudança na biblioteca moment resulta em uma alteração no componente:
O Dependency Inversion Principle nos permite abstrair a implementação específica de uma biblioteca. Por exemplo, no caso do Moment.js ter sido depreciado, se o nosso sistema estiver utilizando diretamente as funcionalidades da biblioteca, a tarefa de migrar para outra biblioteca pode ser muito mais trabalhosa. Porém, se utilizarmos o princípio de inversão de dependência, poderemos reduzir significativamente o impacto dessa mudança, visto que teremos isolado a dependência da biblioteca em apenas um local do nosso código. Dessa forma, ao mudarmos de biblioteca, precisaremos alterar apenas esse local específico, e não todo o sistema.
Segue abaixo um exemplo de como implementar Dependency Inversion Principle com moment usando TypeScript:
E é isso ai galera! O SOLID é uma ferramenta que tem ajudado os programadores a escrever um software mais fácil de entender, mudar e manter. E em conjunto com o React ainda, esses princípios podem ser aplicados para tornar o código mais organizado, estruturado e escalável.
Há muito para descobrir, desse mundo de boas práticas, por isso encorajo vocês a se aventurarem um pouco nesse vasto conteúdo.
