O termo "SOLID" é um acrônimo para cinco princípios utilizados na programação orientada a objetos (POO ou OOP) que possuem o objetivo de facilitar a compreensão, o desenvolvimento e a manutenção de software.

S — Single Responsiblity Principle (Princípio da responsabilidade única).

O — Open-Closed Principle (Princípio Aberto-Fechado).

L — Liskov Substitution Principle (Princípio da substituição de Liskov).

I — Interface Segregation Principle (Princípio da Segregação da Interface).

D — Dependency Inversion Principle (Princípio da inversão da dependência).

Ok, mas porque eu deveria aprender / me importar com isso?

Você provavelmente já utilizou algum site, sistema, aplicativo de celular e/ou vídeo game que não funcionava direito, que apresentava bugs e/ou após utilizar você tinha certeza que aquele software em si era inferior a outros que você já utilizou no passado.

Ou então, após ingressar em uma nova empresa, uma nova equipe, você possui muita dificuldade para entender o código, entender as features que já foram desenvolvidas e até mesmo estender o código. (Acrescentar funcionalidades)

Mas porque isso acontece?

Muito provavelmente porque a pessoa/equipe que escreveu o código não utilizou os princípios SOLID...

Agora vamos para um bom exemplo.

Com certeza você já utilizou algum software da "GAFAM" (Google, Apple, Facebook, Amazon e Microsoft).

Todas essas empresas passam a ideia de:

1- "Robustez" (Não irá "quebrar" enquanto você está utilizando)

2- "Funcionalidade" (O software atende devidamente as solicitações do usuário)

3- "Alta Disponibilidade" (Sempre que você procura por algum produto/serviço ele está lá disponível para você)

Ainda não tive oportunidade de ler o código fonte de nenhum produto/serviço destas empresas, mas tenho certeza que lá dentro, os times utilizam todas as boas práticas possíveis, incluindo o SOLID.

Resumo dos princípios:

1. SRP — Single Responsibility Principle:

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.

Quando estamos aprendendo programação orientada a objetos, sem sabermos, damos a uma

 classe mais de uma responsabilidade e acabamos criando classes que fazem de tudo — God Class*.

Num primeiro momento isso pode parecer eficiente, mas como as responsabilidades acabam se misturando,

quando há necessidade de realizar alterações nessa classe, será difícil modificar uma dessas

responsabilidades sem comprometer as outras. Toda alteração acaba sendo introduzida com um

certo nível de incerteza em nosso sistema — principalmente se não existirem testes automatizados!

2. OCP — Open-Closed Principle:

Princípio Aberto-Fechado — 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.

3. LSP— Liskov Substitution Principle:

Princípio da substituição de Liskov — Uma classe derivada deve ser substituível

por sua classe base.

O princípio da substituição de Liskov foi introduzido por Barbara Liskov em sua

conferência “Data abstraction” em 1987. A definição formal de Liskov diz que:

4. ISP — 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.

Esse princípio basicamente diz que é melhor criar interfaces mais específicas ao

invés de termos uma única interface genérica.

5. DIP — Dependency Inversion Principle:

Princípio da Inversão de Dependência — Dependa de abstrações e não de

implementações.

De acordo com Uncle Bob, esse princípio pode ser definido da seguinte forma:

   1. Módulos de alto nível não devem depender de módulos de baixo nível.

 Ambos devem depender da abstração.

   2. Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.

No contexto da programação orientada a objetos, é comum que as pessoas confundam

 a Inversão de Dependência com a Injeção de Dependência, porém são coisas distintas,

 mas que relacionam entre si com um propósito em comum, deixar o código desacoplado.