Se você já ouviu falar dos Princípios SOLID, é bem provável que conheça o Princípio Aberto/Fechado (ou Open/Closed Principle –OCP) como um dos pilares do design de software orientado a objetos. Mas o que significa exatamente criar sistemas “abertos para extensão e fechados para modificação”?

Neste artigo, vamos explorar esse conceito de maneira prática, com exemplos do mundo real e percepções valiosas que vão além da teoria. Nosso objetivo é mostrar como aplicar o OCP no dia a dia do desenvolvimento de software de forma simples.

O que é o Princípio Aberto/Fechado?

O Princípio Aberto/Fechado afirma que uma classe, módulo ou função deve estar aberta para extensão, mas fechada para modificação. Em outras palavras, nós devemos conseguir estender os comportamentos de um sistema sem alterar o código existente.

O objetivo desse princípio é aumentar a estabilidade do sistema e reduzir o risco de bugs ao introduzir novas funcionalidades, promovendo a ideia de que partes já testadas e funcionais do código não devem ser modificadas.

Por que aplicar o Open/Closed Principle?

Adotar esse conceito traz diversas vantagens para o desenvolvimento de software, por exemplo:

• Redução de riscos: diminui a chance de quebrar funcionalidades que já estão implementadas;
• Facilidade de manutenção: é mais fácil entender e melhorar sistemas modulares (que estão divididos em partes);
• Reutilização de código: promove estruturas reutilizáveis e bem definidas (funcionando como peças de Lego);
• Escalabilidade: facilita o crescimento do sistema sem afetar as partes já desenvolvidas.

Essas vantagens ficam ainda mais claras em sistemas com times grandes ou que precisam de mudanças o tempo todo. Em lugares que usam métodos ágeis, por exemplo, usar o Princípio Aberto/Fechado ajuda a manter a base de código saudável ao longo do tempo.

Como saber o código está aberto para extensão e fechado para modificação?

Descobrir se o seu código segue o OCP nem sempre é simples, mas essas perguntas podem te ajudar nesse processo:

• Eu consigo adicionar uma nova funcionalidade sem precisar mudar o código que já está funcionando? Se sim, seu código está mais preparado para crescer sem causar problemas nas partes que já funcionam.
• Preciso mudar métodos antigos sempre que adiciono algo novo? Se a resposta for “sim”, isso pode ser um sinal de que o código ainda não está bem fechado para modificação.
• Quando uso outras classes, eu me conecto nelas de forma genérica ou dependo diretamente de como elas funcionam por dentro? Se você depende de detalhes internos, seu código pode quebrar se essas classes mudarem. O ideal é se conectar de forma genérica (por exemplo, usando herança ou métodos mais genéricos).
• Tenho vários if ou else para decidir o que fazer com base em tipos ou nomes? Isso costuma significar que você está sempre alterando o código para lidar com casos novos. Tentar separar o comportamento em classes diferentes pode ajudar.
• Se eu quiser um novo comportamento, posso criar uma nova classe em vez de alterar as que já existem? Se sim, seu código provavelmente está seguindo bem o princípio aberto/fechado.

Exemplo de uso do Princípio Aberto/Fechado

❌ Viola a OCP: Para adicionar um novo canal de notificação seria necessário modificar essa classe adicionando outro elif

class NotificationSender:
    def send(self, channel, message):
        if channel == 'email':
            print(f"Sending EMAIL: {message}")
        elif channel == 'sms':
            print(f"Sending SMS: {message}")

✅ Seguindo o OCP: No exemplo abaixo, a classe Notification age como uma abstração, e cada categoria de notificação se apresenta como uma subclasse, ampliando o comportamento sem alterar a classe base. Se amanhã você quiser adicionar PushNotification, não precisa modificar notify_users ou as classes existentes. Só cria uma nova subclasse!

class Notification:
    def send(self, message):
        raise NotImplementedError("Must be implemented by subclass")

class EmailNotification(Notification):
    def send(self, message):
        print(f"Sending EMAIL: {message}")

class SMSNotification(Notification):
    def send(self, message):
        print(f"Sending SMS: {message}")

def notify_users(notifiers, message):
    for notifier in notifiers:
        notifier.send(message)

Dicas práticas para aplicar o Open/Closed Principle no dia a dia

Aplicar o Princípio Aberto/Fechado vai além de conhecer a teoria. Aqui vão algumas práticas que você pode começar a adotar no seu código hoje mesmo:

• Comece pequeno: nem todo código precisa estar 100% aderente ao OCP desde o início. Foque em áreas que mudam com frequência.
• Use interfaces com sabedoria: pense em abstrações desde o começo. Isso te dá flexibilidade futura.
• Evite alterações em código legado estável: prefira estender ao invés de modificar diretamente.
• Revise grandes blocos condicionais: sempre que possível, troque lógicas baseadas em tipo por polimorfismo.

Essas práticas são especialmente úteis em sistemas com microserviços, onde a independência e a extensibilidade de módulos são fatores cruciais para a evolução contínua da arquitetura.

Conclusão

Aplicar o Princípio Aberto/Fechado é uma das formas mais eficazes de criar software sustentável e preparado para o futuro. Ao estruturar seu sistema com base nesse princípio, você reduz o acoplamento, melhora a testabilidade e facilita a evolução contínua da aplicação.

Lembre-se: o código que você escreve hoje provavelmente será alterado amanhã. Então, por que não torná-lo o mais flexível possível desde já?

E você, já aplica o OCP no seu dia a dia de desenvolvimento? Tem dúvidas sobre quando ou como utilizar esse princípio? Compartilhe nos comentários a sua experiência ou exemplos práticos!

Quer se aprofundar ainda mais?

Se você está em busca de aprender mais sobre os princípios SOLID, boas práticas no desenvolvimento de software e padrões de design, vale muito a pena conferir o site Refactoring Guru. Ele oferece conteúdos ricos com explicações visuais e exemplos de código que facilitam o entendimento e ajudam você a evoluir na escrita de um código mais limpo e eficiente.

Além disso, recomendo a leitura do meu outro post: Princípio da Responsabilidade Única: Explicação com Exemplos — uma introdução clara e prática a esse pilar essencial do SOLID!

E, para complementar, aqui está um link para o PDF do livro “Agile Software Development, Principles, Patterns, and Practices” de Robert C. Martin — uma leitura indispensável para quem quer dominar esses conceitos com profundidade!

FAQ – Perguntas Frequentes sobre o Princípio Aberto/Fechado

• Qual é a principal vantagem do Princípio Aberto/Fechado?
  A capacidade de adicionar funcionalidades sem alterar o código existente, evitando regressões e facilitando a manutenção.
• Como saber se minha classe está fechada para modificação?
  Se você consegue adicionar novos comportamentos sem mudar sua estrutura ou assinatura de métodos, ela provavelmente está fechada para modificação.
• Preciso usar interfaces sempre que aplicar o OCP?
  Não necessariamente, mas elas ajudam a estruturar melhor o código e permitem extensões sem modificações diretas.
• O OCP se aplica somente a linguagens orientadas a objetos?
  Embora tenha nascido nesse contexto, o princípio pode ser adaptado a outras abordagens, como programação funcional, desde que o foco seja separação de responsabilidades e extensão segura.