S.O.L.I.D
Nesse artigo vou explicar mais sobre estes fundamentos e trazer algumas ilustrações que vão ajudar bastante no entendimento. Vamos lá?
| ||
Se você trabalha com POO (Programação Orientada a Objetos), provavelmente já ouviu falar em SOLID. | ||
Além de ser um tema muito frequente em entrevistas técnicas e/ou requisitos para vagas, os princípios do SOLID ajudam a escrever um código mais limpo, profissional, elegível e escalável. | ||
Nesse artigo vou explicar mais sobre estes fundamentos e trazer algumas ilustrações que vão ajudar bastante no entendimento. Vamos lá? | ||
| ||
Primeiro de tudo, se você nunca ouviu falar em SOLID, trata-se de um acrônimo (sigla) dos seguintes fundamentos: | ||
| ||
O criador é o conhecido Engenheiro de Software Robert C. Martin, autor de livros como Código Limpo, Arquitetura Limpa e Design Patterns. | ||
Pelos nomes dá pra ter uma ideia muito superficial dos conceitos, então vou aprofundá-los para te ajudar a entender direitinho 😉 | ||
Como citei no início, vou utilizar algumas imagens pra ficar mais didático. As ilustrações utilizadas são da Ugonna Thelma. | ||
S - Single Responsability | ||
O Princípio da Responsabilidade Única defende que uma classe/função/módulo/método deve ter apenas uma única responsabilidade. Se você criar uma função enorme, com várias responsabilidades, fica muito mais difícil pra dar manutenção. Ao alterar uma parte, as outras podem ser afetadas e acabar gerando bugs. | ||
| ||
O - Open/Closed | ||
O Princípio Aberto/Fechado diz que uma classe/função/módulo/método deve ser aberta para extensões porém fechados para modificações. Ou seja, você deve estender aquela classe e adicionar algo a mais, e não modificá-la diretamente. Alterando a classe diretamente, pode afetar o comportamento de outras partes da aplicação que utilizam esta classe, sem que seja o objetivo. | ||
| ||
L - Liskov Substitution | ||
O Princípio da Substituição de Liskov fala que se o objeto "B" é um subtipo de "A", ele deve ser capaz de substituir o "A" (fazer o que é responsabilidade do seu tipo). Um subtipo é um elemento filho (child), ou seja, é uma classe criada a partir de outra (parent). Nesse contexto, o filho deve ser capaz de processar as mesmas requisições e retornar o mesmo resultado que o pai (ou um resultado do mesmo tipo). É o que chamamos de Herança na POO. | ||
| ||
I - Interface Segregation | ||
Segundo o Princípio da Segregação de Interfaces, uma classe não deve requerer ações desnecessárias, ou que não podem ser realizadas. O correto é dividir estas ações em funções específicas para cada tipo de necessidade. | ||
| ||
D - Dependency Inversion | ||
Segundo o Princípio da Inversão de Dependência, classes de níveis mais altos (que executam uma ação com uma ferramenta) não devem depender de classes de níveis mais baixos (necessárias para executar a ação). Ambas devem depender da abstração (interface que contém ambas). Da mesma maneira, a abstração não deve depender de detalhes (como a ferramenta funciona), e sim o contrário - detalhes depende da abstração. Dessa forma, é reduzida a dependência entre os níveis através da utilização da interface. | ||
| ||
Embora alguns princípios sejam parecidos, seus objetivos são diferentes. De qualquer forma, todos são importantes e devem ser aplicados em conjunto para um projeto mais limpo e escalável. | ||
Bastante informação, né? Se é seu primeiro contato com o tema talvez fique um pouco confuso. 😅 Mas calma, não precisa decorar tudo de uma vez só. Aos poucos isso vai se tornando natural. Já deixa o link do artigo salvo nos favoritos pra relembrar quando for necessário. | ||
Obrigada por ler até aqui e nos vemos na próxima! | ||
|
