Please enable JavaScript.
Coggle requires JavaScript to display documents.
Solid - Coggle Diagram
Solid
S — Single Responsiblity Principle (Princípio da responsabilidade única)
Uma classe deve ser especializada apenas em um assunto e possuir apenas uma responsabilidade. O que evita erros como a criação das "God Class", classes sobrecarregadas de funções.
A violação desse princípio gera problemas como:
Falta de coesão, uma vez que a classe assume papéis que não deveria.
Alto acoplamento, ou seja, maior grau de dependência, o que dificulta alterações.
Dificuldades na implementação de testes automatizados.
Dificuldades na implementação de testes automatizados.
O — Open-Closed Principle (Princípio Aberto-Fechado)
Objetos ou entidades devem estar abertos para Extensão, mas fechados para modificação
Ou seja, adições devem ser realizadas sem modificar o código fonte inicial
Dessa forma, evita-se que sejam criados problemas em partes já funcionais do sistema.
L — Liskov Substitution Principle (Princípio da substituição de Liskov)
Objetos de uma subclasse devem ser substituíveis por objetos de sua classe base sem afetar a corretude do programa
Formalmente: Se S é um subtipo de T, então os objetos do tipo T, em um programa, podem ser substituídos pelos objetos de tipo S sem que seja necessário alterar as propriedades deste programa.
Ou seja, em toda situação que é possível usar a superclasse, a subclasse também é aplicável.
D — Dependency Inversion Principle (Princípio da inversão da dependência)
"Os módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações. Além disso, abstrações não devem depender de detalhes. Detalhes devem depender de abstrações."
O DIP ajuda a reduzir o acoplamento no código, melhorando a flexibilidade, extensibilidade e manutenibilidade, reduzindo a propensão a efeitos colaterais de mudanças.
Em outras palavras, o foco é estruturar o código de modo mais abstrato, para que ele seja aplicável a mais cenários concretos.
Isso é alcançado por meio do uso de interfaces ou classes abstratas para definir contratos gerais que os módulos de alto nível (módulos que contêm lógica de negócios) dependem. Os módulos de baixo nível (módulos que contêm detalhes de implementação) devem então implementar essas abstrações.
Isso permite que você inverta o fluxo de controle, tornando as classes de alto nível independentes dos detalhes específicos das classes de baixo nível.
I — Interface Segregation Principle (Princípio da Segregação da Interface)
Uma classe não deve ser forçada a implementar interfaces e métodos que não irão utilizar.
Em outras palavras, é melhor criar interfaces mais específicas ao invés de termos uma única interface genérica.
Dessa forma, evita-se a necessidade de "forçar" um elemento a se encaixar na estrutura.