Carregando
Você aplica o Open Closed Principle ou apenas acha que aplica? Entenda o erro mais comum em projetos Node, APIs e regras de negócio e conquiste um código
O Princípio do SOLID Que 90% dos Devs Aplicam Errado. Você aplica o Open Closed Principle ou apenas acha que aplica? Entenda o erro mais comum em projetos Node, APIs e regras de negócio e conquiste um código elegante e realmente aberto para evolução.
Se você acha que usar IFs para lidar com variações de negócio não tem problema, ou que dar “ctrl+c ctrl+v” em cada novo canal de notificação está tudo certo, você está entre os 90% dos devs que aplicam o Open Closed Principle de forma errada. E pode apostar: é justamente aí que o código começa a deteriorar e fica cada vez menos fácil de manter.
Seu código deve ser facilmente estendido quando surgem novas necessidades — sem que você precise alterar as entranhas do que já existe. É possível absorver novos canais, regras ou integrações sem quebrar o que já funciona. O segredo? Dividir responsabilidades entre objetos e abstrair comportamentos que mudam frequentemente.
A cada novo requisito (como adicionar Push Notification ao lado de Email, WhatsApp ou SMS), se te obriga a alterar métodos, criar mais IFs, elseif e plantar dependências novas, seu código está violando o Open Closed Principle. Ele está fechado ao futuro — e você se vê refatorando sem parar sempre que o negócio muda.
Cada vez que você adiciona uma nova regra de negócio via IF, está abrindo a porta para bugs e tornando seu use case cada vez mais frágil. É apenas uma questão de tempo até você esquecer um fluxo ou engessar o código por completo.
CLI da Anthropic
1. Existem IFs ou switch-cases para decidir qual ação tomar com base em nomes, tipos ou canais? 2. Adicionar algo novo exige mexer no mesmo método use case? 3. O código que decide o canal mexe diretamente com integrações externas? 4. Você sente medo ou dificuldade de dar manutenção quando uma regra muda? Se respondeu sim para algum, o erro está ali.
Eles extraem todo comportamento mutável para objetos próprios e usam padrões de projeto que encapsulam as decisões. Assim, o código principal permanece intocado enquanto comportamentos variam ou crescem. Isso é Open Closed Principle em ação.
Implemente uma interface genérica de “Notificador”, e depois crie uma nova classe para cada canal (WhatsAppNotifier, EmailNotifier, SMSNotifier, etc). Cada classe sabe como notificar naquele canal, e todas seguem a mesma interface. Assim você troca, remove ou adiciona estratégias — sem tocar no resto.
Toda vez que você vê muitos IFs para variações de uma ação, pense: “Eu posso transformar cada opção em uma classe?” Se sim, use Strategy!
Não deixe o use case saber qual notificador usar nem criar new para cada um. Encapsule essa decisão criando uma Factory que recebe o channel/type e retorna a implementação certa. O use case só pede: “me dá o Notifier para esse canal”— e pronto.
Faça como os profissionais: toda chamada externa (Enviar WhatsApp, Email, SMS) deve ficar em um gateway/service específico na pasta resources ou adapters — nunca dentro do use case. O core do seu app trata só lógica de negócio.
Misturar chamadas externas e regra de negócio é receita certa para dor de cabeça e bugs em ambientes produtivos. Separe sempre!
Use sempre que estiver lidando com regras que mudam com frequência (exemplo: formas de notificar, regras tributárias, políticas comerciais, gateways de pagamento). Para lógicas estáveis, não é mandatório.
Depois de refatorar para Strategy + Factory, basta criar uma nova classe de canal e registrar na factory. O use case nem nota! Bugs futuros caem, complexidade baixa e a curva de aprendizado do time reduz. Código limpo é código pronto para o futuro.
IFs não escalam. Toda vez que você soma uma opção nova, dobra as chances de erro. O resultado é um Frankenstein impossível de ler. Com Strategy, você encapsula as diferenças e aplica o verdadeiro poder da Orientação a Objetos.
Se seu use case parece uma árvore de Natal de IFs, pare agora e refatore para aplicar Open Closed Principle.
Testar novas opções fica mais fácil, bugs diminuem nos releases e a confiança em mexer na base do código aumenta. Você ganha respeito do time e reduz dependência de devs “seniores” para mudanças triviais.
1. Identifique comportamentos que mudam rápido no seu sistema. 2. Separe essas variações como Strategies (classes separadas). 3. Crie uma Factory para decidir qual usar. 4. Nunca misture lógica de regra com integrações externas. 5. Teste: adicionar um novo canal não pode exigir mudança no use case.
Não precisa aplicar esse padrão em TODO lugar — escolha pontos do sistema onde a mudança é comum. O segredo é discernimento e prática constante.
Quer ver isso na prática e dominar SOLID do início ao nível avançado? Marque este artigo, refatore um trecho de código do seu projeto hoje e compartilhe sua evolução com a comunidade. Quer se aprofundar de verdade? Confira as videoaulas semanais no canal Dev Doido no YouTube — lá tudo fica ainda mais visual e mão na massa!
Quem aplica Open Closed Principle para de lutar contra o código e começa a curtir criar software. Transforme o “medo de mexer” em orgulho de evoluir sua stack. Quem percebe esse salto nunca mais aceita código Frankenstein.