Os princípios SOLID são um conjunto de cinco diretrizes de design de software que, quando aplicadas, tornam o código mais compreensível, flexível e de fácil manutenção. Eles foram popularizados por Robert C. Martin (Uncle Bob) e são essenciais para qualquer desenvolvedor que deseja criar sistemas robustos e escaláveis. Nesta aula, vamos explorar cada princípio em detalhes, com exemplos em PHP, destacando seus benefícios e situações em que devem ser aplicados.

Embora os princípios SOLID sejam frequentemente associados a linguagens orientadas a objetos, como PHP, eles podem ser aplicados a qualquer paradigma que suporte abstrações e interfaces. Dominar esses princípios é um diferencial para escrever código de alta qualidade, facilitar a colaboração em equipe e reduzir custos de manutenção a longo prazo.

Cada princípio explicado

SOLID é um acrônimo que representa cinco princípios: Single Responsibility Principle (SRP), Open/Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP) e Dependency Inversion Principle (DIP). Cada um aborda um aspecto específico do design de classes e módulos, promovendo coesão, baixo acoplamento e extensibilidade.

Vamos detalhar cada um:

  • S — Single Responsibility Principle (Princípio da Responsabilidade Única): Uma classe deve ter apenas um motivo para mudar, ou seja, deve ter uma única responsabilidade. Isso não significa que a classe tenha apenas um método, mas que todas as suas funcionalidades estejam relacionadas a um único objetivo.
  • O — Open/Closed Principle (Princípio Aberto/Fechado): As entidades de software (classes, módulos, funções) devem estar abertas para extensão, mas fechadas para modificação. Ou seja, você deve ser capaz de adicionar novos comportamentos sem alterar o código existente.
  • L — Liskov Substitution Principle (Princípio da Substituição de Liskov): Objetos de uma classe derivada devem poder substituir objetos da classe base sem afetar a corretude do programa. Em outras palavras, subclasses devem ser substitutas para suas classes pai.
  • I — Interface Segregation Principle (Princípio da Segregação de Interfaces): Muitas interfaces específicas são melhores do que uma única interface geral. Os clientes não devem ser forçados a depender de métodos que não utilizam.
  • D — Dependency Inversion Principle (Princípio da Inversão de Dependência): Dependa de abstrações, não de implementações concretas. Módulos de alto nível não devem depender de módulos de baixo nível; ambos devem depender de abstrações.

Exemplos em PHP

Para entender melhor, vamos ver exemplos práticos de cada princípio em PHP. Começaremos com o SRP.

Single Responsibility Principle Exemplo:

Considere uma classe Relatorio que gera um relatório e também o salva em arquivo. Isso viola o SRP, pois a classe tem duas responsabilidades: gerar o relatório e lidar com a persistência.

class Relatorio {
    public function gerarConteudo(): string {
        return "Conteúdo do relatório";
    }

    public function salvarEmArquivo(string $caminho): void {
        file_put_contents($caminho, $this->gerarConteudo());
    }
}

Para corrigir, separamos as responsabilidades em classes distintas:

class Relatorio {
    public function gerarConteudo(): string {
        return "Conteúdo do relatório";
    }
}

class SalvarRelatorio {
    public function salvar(Relatorio $relatorio, string $caminho): void {
        file_put_contents($caminho, $relatorio->gerarConteudo());
    }
}

Agora cada classe tem uma única responsabilidade, facilitando a manutenção e os testes.

Open/Closed Principle Exemplo:

Suponha que temos uma classe CalculadoraDeDesconto que aplica descontos com base no tipo de cliente. Inicialmente, ela usa uma estrutura de decisão:

class CalculadoraDeDesconto {
    public function calcularDesconto(string $tipoCliente, float $valor): float {
        if ($tipoCliente === 'regular') {
            return $valor * 0.05;
        } elseif ($tipoCliente === 'vip') {
            return $valor * 0.10;
        } else {
            return 0.0;
        }
    }
}

Essa classe não está fechada para modificação: se adicionarmos um novo tipo de cliente, precisaremos alterar a classe. Podemos aplicar o OCP usando polimorfismo:

interface Desconto {
    public function calcular(float $valor): float;
}

class DescontoRegular implements Desconto {
    public function calcular(float $valor): float {
        return $valor * 0.05;
    }
}

class DescontoVip implements Desconto {
    public function calcular(float $valor): float {
        return $valor * 0.10;
    }
}

class CalculadoraDeDesconto {
    public function calcular(Desconto $desconto, float $valor): float {
        return $desconto->calcular($valor);
    }
}

Agora, para adicionar um novo tipo de desconto, basta criar uma nova classe que implemente a interface, sem alterar a calculadora.

Liskov Substitution Principle Exemplo:

Vamos considerar uma hierarquia de formas geométricas. Uma classe Retangulo e uma subclasse Quadrado. Se definirmos métodos setLargura e setAltura, um quadrado violaria o princípio se alterarmos a largura e a altura de forma independente.

class Retangulo {
    protected $largura;
    protected $altura;

    public function setLargura(float $largura): void {
        $this->largura = $largura;
    }

    public function setAltura(float $altura): void {
        $this->altura = $altura;
    }

    public function area(): float {
        return $this->largura * $this->altura;
    }
}

class Quadrado extends Retangulo {
    public function setLargura(float $largura): void {
        $this->largura = $largura;
        $this->altura = $largura;
    }

    public function setAltura(float $altura): void {
        $this->altura = $altura;
        $this->largura = $altura;
    }
}

Isso viola o LSP, pois o comportamento do quadrado difere do retângulo. Uma solução é não usar herança nesse caso, ou modelar uma interface comum Forma com o método area():

interface Forma {
    public function area(): float;
}

class Retangulo implements Forma {
    private $largura;
    private $altura;

    public function __construct(float $largura, float $altura) {
        $this->largura = $largura;
        $this->altura = $altura;
    }

    public function area(): float {
        return $this->largura * $this->altura;
    }
}

class Quadrado implements Forma {
    private $lado;

    public function __construct(float $lado) {
        $this->lado = $lado;
    }

    public function area(): float {
        return $this->lado * $this->lado;
    }
}

Assim, ambos podem ser usados indistintamente onde se espera uma Forma.

Interface Segregation Principle Exemplo:

Considere uma interface Animal com métodos voar() e correr(). Se tivermos um Pinguim, ele não voa, então implementar voar() seria desnecessário. Violamos o ISP ao forçar o pinguim a depender de um método que não usa.

interface Animal {
    public function correr(): void;
    public function voar(): void;
}

class Pinguim implements Animal {
    public function correr(): void {
        echo "Pinguim correndo";
    }

    public function voar(): void {
        throw new Exception("Pinguins não voam");
    }
}

Melhor é segregar as interfaces:

interface Corredor {
    public function correr(): void;
}

interface Voador {
    public function voar(): void;
}

class Pinguim implements Corredor {
    public function correr(): void {
        echo "Pinguim correndo";
    }
}

Agora o pinguim só implementa o que realmente usa.

Dependency Inversion Principle Exemplo:

No DIP, módulos de alto nível não devem depender de módulos de baixo nível. Vamos ver um exemplo de acoplamento rígido:

class EmailService {
    public function enviar(string $mensagem): void {
        // Envia email
    }
}

class Notificacao {
    private $emailService;

    public function __construct() {
        $this->emailService = new EmailService();
    }

    public function enviar(string $mensagem): void {
        $this->emailService->enviar($mensagem);
    }
}

Isso viola o DIP, pois Notificacao depende diretamente de EmailService. Para corrigir, introduzimos uma abstração:

interface ServicoDeMensagem {
    public function enviar(string $mensagem): void;
}

class EmailService implements ServicoDeMensagem {
    public function enviar(string $mensagem): void {
        // Envia email
    }
}

class Notificacao {
    private $servico;

    public function __construct(ServicoDeMensagem $servico) {
        $this->servico = $servico;
    }

    public function enviar(string $mensagem): void {
        $this->servico->enviar($mensagem);
    }
}

Agora, Notificacao depende da abstração, e podemos facilmente trocar o serviço de email por SMS, por exemplo.

Benefícios

A aplicação dos princípios SOLID traz inúmeros benefícios para o desenvolvimento de software:

  • Manutenibilidade: Código mais limpo e organizado, com responsabilidades bem definidas, é mais fácil de entender e modificar.
  • Extensibilidade: Novas funcionalidades podem ser adicionadas sem alterar o código existente, reduzindo o risco de introduzir bugs.
  • Testabilidade: Classes com responsabilidades únicas e dependências injetadas são mais fáceis de testar isoladamente.
  • Reutilização: Componentes bem projetados podem ser reutilizados em diferentes partes do sistema ou em outros projetos.
  • Redução de acoplamento: A dependência de abstrações em vez de implementações concretas reduz o acoplamento entre módulos, tornando o sistema mais flexível.
  • Comunicação: O uso de princípios comuns facilita a comunicação entre desenvolvedores, pois todos seguem as mesmas diretrizes.

Quando aplicar

Os princípios SOLID devem ser aplicados na maioria dos projetos orientados a objetos, mas é importante ter bom senso. Eles são especialmente úteis em sistemas de médio e grande porte, onde a complexidade tende a crescer. No entanto, em projetos muito simples ou protótipos, aplicar rigorosamente todos os princípios pode adicionar complexidade desnecessária.

Aqui estão algumas situações em que cada princípio é particularmente relevante:

  • SRP: Quando uma classe começa a acumular muitas funcionalidades não relacionadas, ou quando você tem dificuldade em descrever o que a classe faz em uma frase.
  • OCP: Quando você prevê que novos comportamentos serão adicionados com frequência, como novos tipos de desconto, formatos de exportação ou algoritmos de cálculo.
  • LSP: Quando você está criando hierarquias de herança e deseja garantir que o polimorfismo funcione corretamente. É importante ao usar frameworks que dependem de contratos (interfaces).
  • ISP: Quando você tem interfaces grandes que forçam classes a implementar métodos que não usam, especialmente em sistemas com muitos clientes diferentes.
  • DIP: Quando você quer desacoplar módulos de alto nível de detalhes de implementação, facilitando testes e a troca de dependências (ex.: usar injeção de dependência).

Na prática, comece identificando cheiros de código que indiquem violações, como classes muito grandes, métodos que fazem muitas coisas, ou dependências rígidas. Aos poucos, refatore o código para aderir aos princípios, sempre priorizando as áreas que mais causam problemas.

Boas práticas e observações finais

Aplicar SOLID não é uma tarefa de uma única vez, mas um hábito contínuo de design. Algumas boas práticas incluem:

  • Escreva testes automatizados para verificar o comportamento das classes, facilitando refatorações seguras.
  • Utilize ferramentas de análise estática para detectar violações de princípios automaticamente.
  • Prefira composição em vez de herança sempre que possível, pois herança tende a violar LSP e OCP.
  • Injete dependências via construtor ou setter, em vez de instanciar dentro da classe.
  • Mantenha as interfaces pequenas e específicas, criando novas quando necessário.

Lembre-se de que SOLID é um guia, não uma regra absoluta. Em alguns casos, seguir o princípio pode adicionar complexidade desnecessária. Avalie o custo-benefício em cada contexto.

Referências

Exercícios

  1. Exercício 1: Identifique uma classe em seu código que viole o SRP e refatore-a em duas ou mais classes com responsabilidades únicas. Descreva as mudanças.

    2. ✓ Resposta: Exemplo: uma classe Pedido que calcula o total e envia email. Refatore em Pedido (dados e cálculo) e EmailService (envio).
  2. Exercício 2: Dado o código abaixo, aplique o OCP para permitir adicionar novos tipos de veículos sem modificar a classe principal. Mostre o código refatorado.
    3. class Veiculo {
    public function calcularCusto(float $distancia): float {
        if ($this->tipo == 'carro') {
            return $distancia * 1.0;
        } elseif ($this->tipo == 'moto') {
            return $distancia * 0.5;
        }
    }
}

    ✓ Resposta: Crie uma interface CalculadoraCusto com método calcular(float $distancia): float, implemente para cada tipo e injete no veículo.
  3. Exercício 3: Explique por que a seguinte hierarquia viola o LSP e como corrigi-la: class Pato extends Passaro onde Passaro tem o método voar(), mas o pato não voa.

    4. ✓ Resposta: Viola porque o pato não pode substituir o pássaro sem alterar o comportamento. Corrija separando em interfaces Voador e Nadador, e fazendo o pato implementar apenas o que usa.
  4. Exercício 4: Crie uma interface grande com 5 métodos e depois segmente-a em pelo menos duas interfaces menores. Mostre um exemplo de classe que implementa apenas uma delas.

    5. ✓ Resposta: Exemplo: interface Trabalhador com métodos trabalhar(), comer(), dormir(), relatar(), treinar(). Segmente em Trabalhador (trabalhar, relatar) e SerVivo (comer, dormir). Uma classe Robo implementa apenas Trabalhador.
  5. Exercício 5: Refatore o código abaixo para aplicar o DIP: class Database { public function query() {} } e class UserRepository { private $db; public function __construct() { $this->db = new Database(); } }

    6. ✓ Resposta: Introduza uma interface DatabaseInterface com método query(), faça Database implementá-la, e injete a interface no construtor de UserRepository.