Na programação de computadores orientada a objetos, o termo SOLID é um acrônimo para cinco postulados de design, destinados a facilitar a compreensão, o desenvolvimento e a manutenção de software.
[S] Single-responsiblity principle
[O] Open-closed principle
[L] Liskov substitution principle
[I] Interface segregation principle
[D] Dependency Inversion Principle
Neste repositório encontraremos implementações de código para exemplificar os princípios SOLID.
O primeiro indício dos princípios SOLID apareceu em 1995, no artigo “The principles of OoD” de Robert C. Martin, também conhecido como "Uncle Bob".
Em 2002, lançou o livro "Agile Software Development, Principles, Patterns, and Practices" que reúne diversos artigos sobre o tema.
A sigla SOLID só foi apresentada mais tarde, por Michael Feathers.
Cada módulo ou classe deve ter responsabilidade sobre uma única parte da funcionalidade fornecida pelo software.
No artigo, Robert C. Martin define uma responsabilidade como um "motivo para mudar" e conclui que uma classe ou módulo deve ter um e apenas um motivo para ser alterado.
Faça uma coisa e faça bem.
Benefícios:
- Teste - Uma classe com uma responsabilidade terá muito menos casos de teste;
- Menor acoplamento - menos funcionalidade em uma única classe terá menos dependências;
- Organização - Classes menores e bem organizadas são mais fáceis de pesquisar do que as classes monolíticas.
Na programação orientada a objeto, o princípio do aberto/fechado estabelece que:
Entidades de software (classes, módulos, funções, etc.) devem ser abertas para extensão, mas fechadas para modificação.
Dessa forma, a entidade pode permitir que o seu comportamento seja estendido sem modificar seu código-fonte.
O nome do princípio aberto/fechado tem sido usado de duas maneiras. Ambas as maneiras usam generalizações (por exemplo, herança, ou delegação de funções) para resolver o aparente dilema, mas os objetivos, as técnicas e os resultados são diferentes.
Quem propôs o princípio de maneira formal e matemática, foi Bárbara Liskov.
Se F(x) é uma propriedade demonstrável sobre objetos x de tipo B. Então F(y) deve ser verdadeiro para objetos y de tipo A, em que A é um subtipo de B.
No entanto, Robert Martin deu uma definição mais simples para ele: "Classes derivadas (ou classes-filhas) devem ser capazes de substituir suas classes-base (ou classes-mães)".
Ou seja, uma classe-filha deve ser capaz de executar tudo que sua classe-mãe faz. Esse princípio se conecta com o polimorfismo e reforça esse pilar da POO.
Nenhum cliente deve ser forçado a depender dos métodos que não usa.
Concluí-se que muitas interfaces de clientes específicas, são melhores do que uma para todos propósitos.
Portanto: interfaces maiores devem ser divididas em menores para garantir que as classes de implementação só precisam se preocupar com os métodos que são do seu interesse.
Deve-se depender de abstrações, não de objetos concretos.
Refere-se à dissociação de módulos de software. Dessa forma, em vez de módulos de alto nível, dependendo de módulos de baixo nível, ambos dependerão de abstrações.
Para cumprir esse princípio, precisamos usar um padrão de design conhecido como padrão de inversão de dependência, geralmente resolvido usando injeção de dependência.
-
Os Princípios do SOLID. Medium, Jones Roberto Nuzzi. 08 de outubro de 2024
-
SOLID. Wikipedia. 09 de outubro de 2024
-
SOLID: o que é e quais os 5 princípios da Programação Orientada a Objetos (POO). Alura. 07 de outubro de 2024