Os princípios SOLID são um conjunto de cinco princípios de design orientado a objetos que foram introduzidos por Robert C. Martin e são considerados essenciais para construir software de qualidade. Esses princípios incluem:

1. SRP (Single Responsibility Principle) - Princípio da Responsabilidade Única
2. OCP (Open-Closed Principle) - Princípio Aberto-Fechado
3. LSP (Liskov Substitution Principle) - Princípio da Substituição de Liskov
4. ISP (Interface Segregation Principle) - Princípio da Segregação de Interfaces
5. DIP (Dependency Inversion Principle) - Princípio da Inversão de Dependência

O Princípio da Responsabilidade Única (SRP) estabelece que cada classe deve ter apenas uma responsabilidade.

O Princípio Aberto-Fechado (OCP) afirma que as classes devem ser abertas para extensão, mas fechadas para modificação.

O Princípio da Substituição de Liskov (LSP) define que os objetos de uma classe filha devem ser capazes de serem substituídos pelos objetos da classe pai.

O Princípio da Segregação de Interfaces (ISP) estabelece que as interfaces devem ser segregadas em responsabilidades menores e mais específicas.

Por fim, o Princípio da Inversão de Dependência (DIP) indica que as classes de nível superior não devem depender de classes de nível inferior, mas sim de abstrações. Vamos abordar os princípios acima em detalhes a seguir.

SRP - Princípio da Responsabilidade Única

O Princípio da Responsabilidade Única (SRP), que afirma que uma classe deve ter apenas uma responsabilidade. Isso significa que a classe deve ter apenas um único propósito e uma única razão para mudar. Um exemplo que pode ilustrar o SRP é uma classe que tem a responsabilidade de calcular o imposto de renda - IRPF e, ao mesmo tempo, gerar um relatório com os valores dos impostos. Essa classe viola o princípio da SRP, pois tem duas responsabilidades diferentes. O ideal seria separar essas duas funcionalidades em duas classes diferentes, onde uma seria responsável pelo cálculo do imposto e outra seria responsável pela geração do relatório.

Outro exemplo, em linguagem Java, ilustra melhor esse princípio. No exemplo, a classe Funcionario tem três responsabilidades: atualizar o salário, promover o funcionário a um novo cargo e salvar o funcionário em um banco de dados. Isso viola o SRP, pois a classe tem mais de uma razão para mudar. Na segunda versão, foram criadas duas classes adicionais, Promocao e BancoDeDados, para lidar com as responsabilidades de promover o funcionário e salvar o funcionário no banco de dados, respectivamente. Dessa forma, a classe Funcionario agora tem apenas uma responsabilidade, tornando o código mais organizado e manutenível.

// Classe sem a aplicação do SRP
public class Funcionario {
    private String nome;
    private String cargo;
    private double salario;
    private int id;

    public Funcionario(String nome, String cargo, double salario, int id) {
        this.nome = nome;
        this.cargo = cargo;
        this.salario = salario;
        this.id = id;
    }

    public void atualizarSalario(double novoSalario) {
        // Atualiza o salário do funcionário
    }

    public void promoverFuncionario(String novoCargo) {
        // Promove o funcionário a um novo cargo
    }

    public void salvarFuncionario(Funcionario funcionario) {
        // Salva o funcionário em um banco de dados
    }
}

// Classe com a aplicação do SRP
public class Funcionario {
    private String nome;
    private String cargo;
    private double salario;
    private int id;

    public Funcionario(String nome, String cargo, double salario, int id) {
        this.nome = nome;
        this.cargo = cargo;
        this.salario = salario;
        this.id = id;
    }

    public void atualizarSalario(double novoSalario) {
        // Atualiza o salário do funcionário
    }

    // Removeu os métodos de promoverFuncionario e salvarFuncionario para outras classes
}

public class Promocao {
    public void promoverFuncionario(Funcionario funcionario, String novoCargo) {
        // Promove o funcionário a um novo cargo
    }
}

public class BancoDeDados {
    public void salvarFuncionario(Funcionario funcionario) {
        // Salva o funcionário em um banco de dados
    }
}

OCP - Princípio Aberto-Fechado

O Princípio Aberto-Fechado (Open-Closed Principle - OCP) afirma que o software deve ser "aberto para extensão" e "fechado para modificação". Isso significa que um software deve ser projetado de tal forma que novos recursos possam ser adicionados sem alterar o código existente. Para isso, o código deve ser separado em módulos que possam ser estendidos ou substituídos por outros módulos.