Please enable JavaScript.
Coggle requires JavaScript to display documents.
Princípios S.O.L.I.D - Coggle Diagram
Princípios S.O.L.I.D
S — Single Responsiblity Principle (Principio de resposabilidade única)
Conceitos
Uma classe deve ter um, e somente um, motivo para mudar.
Classe deve ser especializada em um único assunto e possuir apenas uma responsabilidade/tarefa/ação
Problemas de não se usar
Falta de coesão
Alto acoplamento
Dificuldades na implementação de testes automatizados
Dificuldades para reaproveitar o código
Principal Beneficio
automaticamente você estará escrevendo um código mais limpo e de fácil manutenção!
O — Open-Closed Principle (Princípio Aberto-Fechado)
Conceitos
Objetos ou entidades devem estar abertos para extensão, mas fechados para modificação.
Quando novos comportamentos e recursos precisam ser adicionados no software, devemos estender e não alterar o código fonte original.
Principal Beneficio
Facilidade na adição de novos requisitos, diminuindo as chances de introduzir novos bugs
Problemas de não se usar
Alterar uma classe já existente para adicionar um novo comportamento, corremos um sério risco de introduzir bugs em algo que já estava funcionando.
L — Liskov Substitution Principle (Princípio da substituição de Liskov)
Conceitos
Uma classe derivada deve ser substituível por sua classe base.
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.
Beneficios
Permite usar o polimorfismo com mais confiança.
Problemas de não se usar
Sobrescrever/implementar um método que não faz nada
Retornar valores de tipos diferentes da classe base
I — Interface Segregation Principle (Princípio da Segregação da Interface)
Conceitos
Uma classe não deve ser forçada a implementar interfaces e métodos que não irão utilizar.
Problemas de não seguir
Interfaces genéricas e nada específica às classes, pode gerar complexidade e difícil manutenção posterior ao código.
Beneficios
Facilidade de manutenção, Coesão e Eficiência
D — Dependency Inversion Principle (Princípio da inversão da dependência)
Conceitos
Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender da abstração.
Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.
Beneficios
Desaclopamento
Problema de não se usar
Código e aplicação acaba se tornando altamaente aclopado