O que é SOLID?

SOLID é um acrônimo dos cinco primeiros princípios da programação orientada a objetos e design de código identificados por Robert C. Martin (ou Uncle Bob) por volta do ano 2000. O acrônimo SOLID foi introduzido por Michael Feathers, após observar que os cinco princípios poderiam se encaixar nesta palavra.

Single Responsibility Principle (SRP)

Open-Closed Principle (OCP)

Liskov Substitution Principle (LSP)

Interface Segregation Principle (ISP)

Dependency Inversion Principle (DIP)

Benefícios de utilizar os princípios SOLID

• Seja fácil de se manter, adaptar e se ajustar às alterações de escopo;
• Seja testável e de fácil entendimento;
• Seja extensível para alterações com o menor esforço necessário;
• Que forneça o máximo de reaproveitamento;
• Que permaneça o máximo de tempo possível em utilização.

SRP — Princípio da Responsabilidade Única

Uma classe deve ter um, e somente um, motivo para mudar.

Esse princípio declara que uma classe deve ser especializada em um único assunto e possuir apenas uma responsabilidade dentro do software, ou seja, a classe deve ter uma única tarefa ou ação para executar.

OCP — Princípio Aberto-Fechado

Deve ser possível de estender um comportamento de uma classe, sem modificá-lo.

Objetos ou entidades devem estar abertos para extensão, mas fechados para modificação, ou seja, quando novos comportamentos e recursos precisam ser adicionados no software, devemos estender e não alterar o código fonte original.

LSP — Princípio da Substituição de Liskov

As classes base devem ser substituíveis por suas classes derivadas.

O princípio da substituição de Liskov foi introduzido por Barbara Liskov em sua conferência “Data abstraction” em 1987.

Objetos em um programa devem ser substituíveis por instâncias de seus subtipos, sem alterar a funcionalidade do programa. Deve ser capaz de afetar apenas a especificação da classe.

ISP — Princípio da Segregação de Interface

Muitas interfaces específicas são melhores do que uma interface única.

Esse princípio basicamente diz que é melhor criar interfaces mais específicas ao invés de termos uma única interface genérica. Isto para não forçar uma classe a implementar um método que ela não vai usar.

DIP — Princípio da Inversão de Dependência

Dependa de uma abstração e não de uma implementação.

O princípio de inversão de dependências diz respeito à depender de uma abstração e não de uma implementação. Nesse caso, todos os demais princípios são aplicados, garantindo que os sistemas sejam o mais desacoplados e coesos possível. Para isso, recomenda-se trabalhar com a injeção de dependências. Em linhas gerais, “Injetar” uma dependência, nada mais é que passar uma classe (habitualmente uma classe interface) que será utilizada, para outra que irá consumir seus recursos.

Conheça meu projeto! https://4devs.net.br