Princípios SOLID: Open/Closed

1. Introdução ao Princípio Open/Closed (OCP)

O Princípio Open/Closed (OCP) é o segundo dos cinco princípios SOLID de design orientado a objetos, formulado originalmente por Bertrand Meyer em 1988. Sua definição clássica estabelece que entidades de software (classes, módulos, funções) devem estar abertas para extensão, mas fechadas para modificação. Isso significa que você deve projetar seus componentes de forma que novos comportamentos possam ser adicionados sem precisar alterar o código já existente e testado.

No contexto da Arquitetura de Software, o OCP é fundamental para reduzir riscos em manutenções evolutivas. Quando um sistema precisa de novas funcionalidades, modificar código legado pode introduzir bugs em partes que já funcionam. Ao seguir o OCP, você cria um design onde extensões são feitas através de novas classes ou módulos, preservando a estabilidade do código-base.

2. Entendendo o Conceito de “Aberto” e “Fechado”

Fechado para modificação significa que o código fonte de um módulo existente não deve ser alterado para acomodar novos requisitos. Uma vez que o módulo foi testado e aprovado, ele permanece intocado.

Aberto para extensão significa que o mesmo módulo deve permitir que seu comportamento seja estendido, geralmente através de herança, composição ou injeção de dependências.

Em nível de classe, o OCP é implementado com abstrações (interfaces ou classes abstratas). Em nível arquitetural, ele se manifesta em módulos independentes que se comunicam através de interfaces bem definidas, como em arquiteturas de plugins ou microsserviços.

3. Violações Comuns do OCP e Seus Problemas

A violação mais frequente do OCP é o uso excessivo de condicionais (if/else ou switch) para tratar cada novo caso. Exemplo clássico:

class CalculadoraDeFrete {
    public double calcular(String tipo, double peso) {
        if (tipo.equals("SEDEX")) {
            return peso * 1.5 + 10;
        } else if (tipo.equals("PAC")) {
            return peso * 1.0 + 5;
        } else if (tipo.equals("JADLOG")) {
            return peso * 1.2 + 8;
        }
        throw new IllegalArgumentException("Tipo desconhecido");
    }
}

Problemas: cada nova transportadora exige modificar a classe existente, criando efeito cascata em testes e aumentando o débito técnico. O acoplamento rígido com implementações concretas dificulta a manutenção.

4. Estratégias para Implementar o OCP

Uso de abstrações: interfaces e classes abstratas servem como contratos estáveis que não mudam, enquanto as implementações podem variar.

Padrão Strategy: encapsula algoritmos intercambiáveis. Útil quando você tem diferentes comportamentos para uma mesma operação.

Padrão Template Method: define o esqueleto de um algoritmo em um método, permitindo que subclasses implementem passos específicos sem alterar a estrutura geral.

5. OCP na Prática: Exemplo com Código

Exemplo 1: Sistema de relatórios – violação com if por tipo

// Violação do OCP
class GeradorRelatorio {
    public void gerar(String tipo) {
        if (tipo.equals("PDF")) {
            // lógica para PDF
        } else if (tipo.equals("CSV")) {
            // lógica para CSV
        } else if (tipo.equals("HTML")) {
            // lógica para HTML
        }
    }
}

Refatoração seguindo OCP:

// Interface estável (aberta para extensão)
interface Relatorio {
    void gerar(String dados);
}

// Implementações concretas
class RelatorioPDF implements Relatorio {
    public void gerar(String dados) {
        // lógica específica para PDF
    }
}

class RelatorioCSV implements Relatorio {
    public void gerar(String dados) {
        // lógica específica para CSV
    }
}

// Cliente fechado para modificação
class GeradorRelatorio {
    private Relatorio relatorio;

    public GeradorRelatorio(Relatorio relatorio) {
        this.relatorio = relatorio;
    }

    public void gerar(String dados) {
        relatorio.gerar(dados);
    }
}

// Novo formato sem modificar código existente
class RelatorioJSON implements Relatorio {
    public void gerar(String dados) {
        // lógica para JSON
    }
}

Exemplo 2: Validação de regras de negócio

// Violação: condicional para cada regra
class ValidadorPedido {
    public boolean validar(Pedido pedido) {
        if (pedido.getValor() < 0) return false;
        if (pedido.getCliente() == null) return false;
        if (pedido.getItens().isEmpty()) return false;
        return true;
    }
}

Refatoração com OCP:

interface RegraValidacao {
    boolean validar(Pedido pedido);
}

class ValorPositivo implements RegraValidacao {
    public boolean validar(Pedido pedido) {
        return pedido.getValor() >= 0;
    }
}

class ClienteObrigatorio implements RegraValidacao {
    public boolean validar(Pedido pedido) {
        return pedido.getCliente() != null;
    }
}

class ValidadorPedido {
    private List<RegraValidacao> regras;

    public ValidadorPedido(List<RegraValidacao> regras) {
        this.regras = regras;
    }

    public boolean validar(Pedido pedido) {
        return regras.stream().allMatch(r -> r.validar(pedido));
    }
}

Agora, novas regras são adicionadas criando novas classes que implementam RegraValidacao, sem modificar o ValidadorPedido.

6. OCP e Outros Princípios SOLID

Single Responsibility: cada classe tem um único motivo para mudar, o que naturalmente facilita a extensão sem modificar código existente.

Liskov Substitution: subtipos devem ser substituíveis por seus tipos base sem alterar o comportamento esperado. Se uma subclasse viola LSP, a extensão via herança quebra o OCP.

Interface Segregation: interfaces coesas e específicas evitam que implementações sejam forçadas a depender de métodos que não usam, facilitando a adição de novas implementações sem modificar as existentes.

7. OCP em Escala Arquitetural: Módulos e Plugins

Em sistemas de e-commerce, módulos de pagamento são um exemplo clássico. Cada gateway (PayPal, Stripe, Mercado Pago) é um plugin que implementa uma interface GatewayPagamento. O core do sistema nunca precisa ser modificado para adicionar um novo gateway.

interface GatewayPagamento {
    boolean processarPagamento(double valor, String dadosCartao);
}

class PagamentoPayPal implements GatewayPagamento { ... }
class PagamentoStripe implements GatewayPagamento { ... }

// Novo gateway adicionado sem modificar o core
class PagamentoPix implements GatewayPagamento { ... }

O mesmo padrão se aplica a sistemas de notificações (e-mail, SMS, push). Cada novo canal de notificação é um módulo independente que implementa uma interface Notificador, seguindo o princípio da Inversão de Dependência (DIP) para estabilizar as camadas de alto nível.

8. Desafios e Boas Práticas com OCP

Cuidado com abstrações prematuras: nem todo ponto de variação precisa de uma interface. Se você tem apenas uma implementação e não prevê variações futuras, aplicar OCP pode adicionar complexidade desnecessária. O princípio YAGNI (You Ain't Gonna Need It) sugere adiar abstrações até que sejam realmente necessárias.

Equilíbrio entre flexibilidade e complexidade: muitas abstrações podem tornar o código difícil de navegar. Use OCP onde há expectativa real de variação, como em regras de negócio, formatos de saída ou integrações externas.

Testabilidade: o OCP facilita a criação de mocks e testes unitários. Ao depender de abstrações, você pode substituir implementações reais por mocks em testes, isolando a unidade sob teste.

Referências