Baixe o material de estudo
Hoje vamos mergulhar em um dos tópicos mais importantes da engenharia de software e da programação orientada a objetos (POO): os princípios SOLID. Longe de serem apenas teoria, esses cinco princípios são a base para construir sistemas robustos, flexíveis e fáceis de manter. Para as bancas de concurso, questões sobre SOLID são a forma perfeita de avaliar se o candidato entende de fato sobre boas práticas e arquitetura de software.
Vamos desvendar cada uma dessas letras!
O que é SOLID?
SOLID é um acrônimo mnemônico para cinco princípios de design de software, introduzidos por Robert C. Martin (conhecido como “Uncle Bob”). O objetivo é simples: combater os problemas de um software mal projetado, como alta rigidez (difícil de mudar), fragilidade (quebra em vários lugares a cada mudança) e baixa reutilização.
Dominar SOLID é o que diferencia um código que apenas “funciona” de um código profissional e de alta qualidade.
(S) – Single Responsibility Principle (Princípio da Responsabilidade Única)
O que diz? “Uma classe deve ter um, e somente um, motivo para mudar.”
Cada classe deve ter uma única responsabilidade ou tarefa bem definida. Se uma classe faz muitas coisas diferentes, qualquer pequena alteração pode gerar efeitos colaterais inesperados.
class Funcionario {
public double calculaSalario() { /*…*/ }
public void salvaFuncionarioNoBanco() { /*…*/ }
public String geraRelatorioHoras() { /*…*/ }
}
Essa classe calcula salário, interage com o banco de dados e gera relatórios. Ela tem três motivos para ser alterada.
- Solução (Aplicando SRP):
class Funcionario {
// Apenas dados e regras de negócio do funcionário
}
class CalculadoraSalario {
public double calcula(Funcionario f) { /*…*/ }
}
class FuncionarioRepository {
public void salva(Funcionario f) { /*…*/ }
}
Agora, cada classe tem uma única e clara responsabilidade.
(O) – Open/Closed Principle (Princípio Aberto/Fechado)
O que diz? “Entidades de software (classes, módulos, funções) devem estar abertas para extensão, mas fechadas para modificação.”
Você deve ser capaz de adicionar novas funcionalidades sem alterar o código-fonte existente. Isso geralmente é alcançado com o uso de interfaces e polimorfismo.
class Pagamento {
public void pagar(String tipo) {
if (tipo.equals(“boleto”)) { /* Lógica do boleto */ }
if (tipo.equals(“cartao”)) { /* Lógica do cartão */ }
// Para adicionar PIX, preciso alterar essa classe!
}
}
- Solução (Aplicando OCP):
interface MetodoPagamento {
void pagar();
}
class PagamentoBoleto implements MetodoPagamento {
public void pagar() { /* Lógica do boleto */ }
}
class PagamentoCartao implements MetodoPagamento {
public void pagar() { /* Lógica do cartão */ }
}
// Para adicionar PIX, basta criar uma nova classe. A classe Pagamento não muda.
(L) – Liskov Substitution Principle (Princípio da Substituição de Liskov)
O que diz? “Subtipos devem ser substituíveis por seus tipos base sem quebrar a aplicação.”
Se uma classe Filha herda de uma classe Pai, você deve poder usar um objeto da classe Filha em qualquer lugar que um objeto da classe Pai seja esperado, sem causar resultados incorretos. Isso garante que a herança seja usada corretamente.
- Problema Clássico: O Quadrado não é um Retângulo.
class Retangulo {
protected int altura, largura;
public void setAltura(int a) { this.altura = a; }
public void setLargura(int l) { this.largura = l; }
}
class Quadrado extends Retangulo {
// Para ser um quadrado, altura e largura devem ser iguais!
@Override
public void setAltura(int a) { this.altura = a; this.largura = a; }
@Override
public void setLargura(int l) { this.altura = l; this.largura = l; }
}
Se um método espera um Retangulo e recebe um Quadrado, o comportamento pode ser inesperado, violando o LSP. A solução é repensar a hierarquia de herança.
(I) – Interface Segregation Principle (Princípio da Segregação de Interfaces)
O que diz? “Uma classe não deve ser forçada a implementar interfaces e métodos que não irá utilizar.”
Em outras palavras: É melhor ter várias interfaces pequenas e específicas do que uma única interface grande e genérica.
interface Trabalhador {
void trabalhar();
void almocar();
}
class Humano implements Trabalhador { /* implementa os dois */ }
class Robo implements Trabalhador {
public void trabalhar() { /* ok */ }
public void almocar() { /* um robô não almoça! */ }
}
A classe Robo é forçada a implementar um método que não faz sentido para ela.
- Solução (Aplicando ISP):
interface Trabalhavel { void trabalhar(); }
interface Comestivel { void almocar(); }
class Humano implements Trabalhavel, Comestivel { /* ok */ }
class Robo implements Trabalhavel { /* ok */ }
(D) – Dependency Inversion Principle (Princípio da Inversão de Dependência)
O que diz? “Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações. Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.”
Sua classe não deve depender de uma implementação concreta, mas sim de uma interface (abstração). Isso desacopla o código e facilita a troca de implementações. É a base da Injeção de Dependência.
class Notificador {
private EmailService email = new EmailService(); // Acoplamento forte!
public void notificar() {
email.enviarEmail();
}
}
Se quisermos notificar por SMS, teremos que alterar a classe Notificador.
- Solução (Aplicando DIP):
interface ServicoNotificacao {
void enviar();
}
class Notificador {
private ServicoNotificacao servico;
public Notificador(ServicoNotificacao servico) { // Dependência é injetada
this.servico = servico;
}
public void notificar() {
servico.enviar();
}
}
Bora ver como esse assunto é cobrado nos concursos!
1. (INSTITUTO AOCP/ESPECIALISTA DE TIC/PRODEB/2018)
Com base no modelo SOLID utilizado como referência para padrões de projeto e princípios arquiteturais, um dos seus princípios denominados de LSP ( Liskov substitution principle) diz respeito ao fato de que
- uma classe deve ter apenas uma razão para mudar, sendo coesa.
- os objetos devem ser substituíveis com instâncias de seus tipos base, sem prejudicar o funcionamento do software.
- todo o processo de desenvolvimento de software deve ser baseado em abstrações, já que elas pouco mudam.
- deve-se utilizar o conceito de herança o máximo possível, estendendo para todo e qualquer atributo que possua alguma semelhança.
- os módulos devem ser enxutos tendo poucos comportamentos.
COMENTÁRIO
A alternativa correta é a B. O Princípio da Substituição de Liskov (LSP) estabelece que os objetos de uma superclasse devem ser substituíveis por objetos de suas subclasses sem alterar o funcionamento correto do software. Em outras palavras, uma classe derivada deve poder ser usada no lugar de sua classe base sem causar erros ou comportamentos inesperados. As outras alternativas estão incorretas, pois a opção A descreve o Princípio da Responsabilidade Única (SRP) e a C se refere ao Princípio da Inversão de Dependência (DIP).
2. (INSTITUTO AOCP/TÉCNICO/MPE-RS/2025)
Os padrões arquiteturais de software definem diretrizes para a organização e a estruturação de sistemas, facilitando a escalabilidade, a manutenção e a reutilização de código. O SOLID é um conjunto de princípios de design que auxiliam na criação de software mais flexível e sustentável. Em relação ao Open/Closed Principle (OCP), um dos princípios do SOLID, assinale a alternativa correta.
- Aberto para substituição, fechado para segregação.
- Aberto para extensão, fechado para modificação.
- Aberto para segregação, fechado para inversão.
- Aberto para inversão, fechado para extensão.
- Aberto para modificação, fechado para substituição.
COMENTÁRIO
A alternativa correta é a B. O Princípio Aberto/Fechado (Open/Closed Principle – OCP) estabelece que as entidades de software, como classes e módulos, devem ser “abertas para extensão, mas fechadas para modificação”. Na prática, isso significa que devemos ser capazes de adicionar novas funcionalidades a um sistema sem alterar o código-fonte existente que já foi testado e está em funcionamento, o que geralmente é alcançado através do uso de abstrações, como herança ou interfaces, para estender o comportamento do sistema de forma segura e sustentável.
3. (CEBRASPE/ANALISTA/SERPRO/2023)
A respeito de clean code, julgue o item que se segue.
O princípio de segregação de interface do SOLID determina a responsividade, em que uma mesma interface atende a vários aparelhos, sem necessidade de modificações individuais.
COMENTÁRIO
O item está errado. O Princípio da Segregação de Interface (Interface Segregation Principle – ISP) do SOLID não se refere à responsividade de design para diferentes aparelhos, mas sim à arquitetura do código. Este princípio estabelece que os clientes (classes) não devem ser forçados a depender de métodos de interface que não utilizam, defendendo a criação de interfaces menores e mais específicas em vez de uma única interface grande e monolítica. O objetivo é aumentar a coesão e reduzir o acoplamento no sistema, um conceito distinto da adaptabilidade de interfaces de usuário a diferentes dispositivos.
Conclusão
Os princípios SOLID são mais do que um conjunto de regras; são uma filosofia para escrever software de maneira organizada, desacoplada e testável. Para sua prova, entender a definição e o propósito de cada um é fundamental. Muitas questões se resumem a identificar qual princípio se aplica a um determinado cenário ou trecho de código.
Estude-os bem, pois esse conhecimento é um passaporte para a aprovação e para uma carreira sólida como desenvolvedor!
Abraços e até a próxima jornada!
Fonte: Gran Cursos Online
Download disponível – Princípios SOLID – Domine a Essência de um Código Profissional