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
Por que isso é importante
Resposta direta: em “SOLID Open Closed Principle: O Erro Que 90% dos Devs”, meça no seu contexto — hype e ranking não substituem eval e aceite.
Por que isso é importante
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.
Só 1 em cada 10 realmente entende o Open Closed Principle
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.
O que significa estar ABERTO para extensão e FECHADO para modificação?
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.
O erro assassino: Modificar ao invés de estender
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.
Atenção
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.
Como identificar se você está aplicando errado (checklist rápido)
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.
O segredo dos devs que nunca sofrem refatorando APIs
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.
Padrão Strategy: Dê um nome para o que muda
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.
Dica técnica
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!
Padrão Factory Method: Decida quem instancia o quê
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.
Otimização real: separando regra de negócio de integração
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.
Alerta de Arquitetura
Misturar chamadas externas e regra de negócio é receita certa para dor de cabeça e bugs em ambientes produtivos. Separe sempre!
Quando vale MESMO aplicar Open Closed Principle?
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.
Yes! O código agora está preparado para crescer
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.
A armadilha dos IFs
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.
Evite a armadilha
Se seu use case parece uma árvore de Natal de IFs, pare agora e refatore para aplicar Open Closed Principle.
Código limpo: o que realmente muda depois
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.
Resumo prático: Checklist para agir nesta semana
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.
Atenção final
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.
Só aprende de verdade quem pratica (CONVITE)
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!
O anti-IF: o código do futuro é extensível
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.
Perguntas frequentes
Por que «O que significa estar ABERTO para extensão e FECHADO para modificação?» importa em SOLID Open Closed Principle: O Erro Que 90% dos Devs?
Do texto: 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.
Qual primeiro passo concreto em «O erro assassino: Modificar ao invés de estender»?
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. Em «O erro assassino: Modificar ao invés de estender», o texto trata isso como prática — não como slogan.
Como «Como identificar se você está aplicando errado (checklist rápido)» se conecta ao resto do método?
Comece pelo mecanismo descrito: 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.
Quando «O segredo dos devs que nunca sofrem refatorando APIs» não deve ser a prioridade?
Use o critério do material: 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. Se precisar de segundo sinal, 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.
Perguntas frequentes
Por que «O que significa estar ABERTO para extensão e FECHADO para modificação?» importa em SOLID Open Closed Principle: O Erro Que 90% dos Devs?
Do texto: 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.
Qual primeiro passo concreto em «O erro assassino: Modificar ao invés de estender»?
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. Em «O erro assassino: Modificar ao invés de estender», o texto trata isso como prática — não como slogan.
Como «Como identificar se você está aplicando errado (checklist rápido)» se conecta ao resto do método?
Comece pelo mecanismo descrito: 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.
Quando «O segredo dos devs que nunca sofrem refatorando APIs» não deve ser a prioridade?
Use o critério do material: 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. Se precisar de segundo sinal, 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.
O que significa estar ABERTO para extensão e FECHADO para modificação?
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.
Como identificar se você está aplicando errado (checklist rápido)
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.
Quando vale MESMO aplicar Open Closed Principle?
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.