O acrônimo SOLID representam um conjunto de princípios no contexto da Programação Orientada a Objetos. A ideia foi introduzida por Robert C. Martin (Uncle Bob) e tem como objetivo tornar os designs de software mais compreensíveis, flexíveis e facilitar a manutenção.
Aqui está um resumo dos princípios:
| Principle | Significado | Benefícios |
|---|---|---|
| Single Responsibility Principle (SRP) | Uma classe deve ter apenas uma razão para mudar. Essencialmente, deve ter apenas uma responsabilidade ou trabalho. | Ele ajuda a obter a separação de preocupações no design do software. Quando são necessárias alterações, elas geralmente podem ser feitas sem afetar outras partes do sistema. |
| Open - Closed Principle (OCP) | As entidades de software (como classes, módulos, funções etc.) devem ser abertas para extensão, mas fechadas para modificação. Isso implica que o comportamento de um módulo pode ser estendido sem modificar seu código-fonte. | Ele permite adicionar novas funcionalidades sem alterar o código existente, o que reduz o risco de introdução de bugs em códigos que já estão funcionando. |
| Liskov Substitution Principle (LSP) | Os objetos de uma superclasse devem poder ser substituídos por objetos de uma subclasse sem afetar a correção do programa. Em outras palavras, uma classe derivada deve ser substituível por sua classe base. | Ele garante que uma classe derivada não introduza um comportamento inesperado quando usada no lugar da classe base. |
| Interface Segregation Principle (ISP) | Os clientes não devem ser forçados a depender de interfaces que não usam. Em vez de ter uma interface grande e abrangente, geralmente é melhor ter várias interfaces menores e específicas. | Ele garante que uma classe não seja sobrecarregada com métodos de que não precisa. Isso leva a designs mais focados e fáceis de entender. |
| Dependency Inversion Principle (DIP) | 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, as abstrações não devem depender de detalhes. Os detalhes devem depender das abstrações. | Ela ajuda a desacoplar os módulos de software. Quando os componentes de nível superior dependem de abstrações em vez de implementações concretas de componentes de nível inferior, você obtém mais flexibilidade no sistema, facilitando a mudança e a adaptação ao longo do tempo. |
O que é um “princípio”?
- Os princípios SOLID não são regras. Não são verdades perfeitas. São bons conselhos.
- A ideia é nomear um conceito para que se possa falar e racionalizar sobre ele.
- Esses princípios são heurísticas. São soluções de senso comum para problemas comuns.
- São de natureza empírica. Funcionam em muitos casos, mas não há prova que sempre vão funcionar, nem que devem ser sempre seguidos.
- Os princípios não tornam um programador ruim em um programador bom. Precisam ser aplicados com pensamento crítico. Se forem aplicados mecanicamente, será tão mau como se não fossem aplicados de todo.
- Não é preciso concordar com todos, não é preciso sempre aplicar com os que concorda. Mas é bom conhecê-los. O conhecimento deles permite justificar a decisão de quando e onde aplicá-los.
O que é uma “responsabilidade” ?
- No contexto do princípio, uma responsabilidade é um “motivo para mudança”.
- Se consegue pensar em mais de um motivo para mudar uma classe, então ela tem mais de uma responsabilidade.
Sources
Encontrei no YouTube um link para uma playlist interessante do canal DevEficiente. Acho que é uma boa fonte para início de compreensão e aprofundamento.
- MARTIN, R. C. Getting a SOLID start. Clean Code Blog https://sites.google.com/site/unclebobconsultingllc/getting-a-solid-start (2009).
- Brewer, E. C. SRP: The Single Responsibility Principle.