Open/Closed Principle
Aberto para extensão, fechado para modificação
Você deve poder adicionar funcionalidades sem modificar código existente.
Explicando como se você tivesse 5 anos
Agora sim! 🎉
É como ter um bloco de Lego. Você não quebra o bloco para mudá-lo, você encaixa novos blocos nele!
Por que isso é uma Red Flag?
Atenção ao problema! ⚡
Código que viola OCP requer modificação de classes existentes toda vez que nova funcionalidade é adicionada, aumentando risco de bugs. Indica falta de abstrações adequadas e design rígido. Cada mudança pode quebrar código existente que estava funcionando. A oportunidade está em usar interfaces e polimorfismo para tornar o código extensível sem modificação.
Para que serve
Permitir que o código seja estendido sem modificar implementações existentes.
Explicação Detalhada
O Princípio Aberto/Fechado diz que entidades de software devem estar abertas para extensão mas fechadas para modificação. Isso significa que podemos adicionar novos comportamentos sem alterar código existente, reduzindo o risco de bugs. Isso é alcançado através de abstrações (interfaces, classes abstratas) e polimorfismo. Exemplo: em vez de um switch-case gigante, use uma interface e diferentes implementações.
História
Bertrand Meyer introduziu este princípio em seu livro "Object-Oriented Software Construction". A ideia é que software deve ser estável (fechado para modificação) mas flexível (aberto para extensão).
Quem Inventou
Bertrand Meyer
Ano: 1988
Compartilhar
Relacionadas
Single Responsibility Principle
Cada coisa faz só uma tarefa
Liskov Substitution Principle
Subtipos devem ser substituíveis por seus tipos base
Interface Segregation Principle
Não obrigue ninguém a depender do que não usa
Dependency Inversion Principle
Dependa de abstrações, não de implementações concretas
Explicando como se você tivesse 5 anos
Agora sim! 🎉
É como ter um bloco de Lego. Você não quebra o bloco para mudá-lo, você encaixa novos blocos nele!
Por que isso é uma Red Flag?
Atenção ao problema! ⚡
Código que viola OCP requer modificação de classes existentes toda vez que nova funcionalidade é adicionada, aumentando risco de bugs. Indica falta de abstrações adequadas e design rígido. Cada mudança pode quebrar código existente que estava funcionando. A oportunidade está em usar interfaces e polimorfismo para tornar o código extensível sem modificação.
História
Bertrand Meyer introduziu este princípio em seu livro "Object-Oriented Software Construction". A ideia é que software deve ser estável (fechado para modificação) mas flexível (aberto para extensão).
Quem Inventou
Bertrand Meyer
Ano: 1988
Para que serve
Permitir que o código seja estendido sem modificar implementações existentes.
Explicação Detalhada
O Princípio Aberto/Fechado diz que entidades de software devem estar abertas para extensão mas fechadas para modificação. Isso significa que podemos adicionar novos comportamentos sem alterar código existente, reduzindo o risco de bugs. Isso é alcançado através de abstrações (interfaces, classes abstratas) e polimorfismo. Exemplo: em vez de um switch-case gigante, use uma interface e diferentes implementações.
Heurísticas Relacionadas
Single Responsibility Principle
Cada coisa faz só uma tarefa
Liskov Substitution Principle
Subtipos devem ser substituíveis por seus tipos base
Interface Segregation Principle
Não obrigue ninguém a depender do que não usa
Dependency Inversion Principle
Dependa de abstrações, não de implementações concretas
Fontes e Referências
Quer se aprofundar? Confira essas fontes oficiais: