Qual é o significado e o raciocínio por trás do Princípio Aberto/Fechado?

Question

O Princípio Aberto/Fechado afirma que as entidades de software (classes, módulos, etc.) devem ser abertas para extensão, mas fechadas para modificação.O que isso significa e por que é um princípio importante de um bom design orientado a objetos?

Answer 1

Especificamente, trata-se de um "Santo Graal" de design em OOP de tornar uma entidade extensível o suficiente (através de seu design individual ou através de sua participação na arquitetura) para suportar futuras mudanças imprevistas sem reescrever seu código (e às vezes até mesmo sem recompilar). **).

Algumas maneiras de fazer isso incluem Polimorfismo/Herança, Composição, Inversão de Controle (também conhecido comoDIP), Programação Orientada a Aspectos, Padrões como Estratégia, Visitante, Método de Modelo e muitos outros princípios, padrões e técnicas de OOAD.

** Veja os 6 “princípios do pacote”, REP, CCP, CRP, ADP, SDP, SAP

Answer 2

Isso significa que você deve colocar novo código em novas classes/módulos.O código existente deve ser modificado apenas para correção de bugs.Novas classes podem reutilizar código existente por meio de herança.

O princípio aberto/fechado destina-se a mitigar o risco ao introduzir novas funcionalidades.Como você não modifica o código existente, pode ter certeza de que ele não será quebrado.Reduz o custo de manutenção e aumenta a estabilidade do produto.

Answer 3

É a resposta para o frágil problema da classe base, que diz que modificações aparentemente inocentes nas classes base podem ter consequências não intencionais para os herdeiros que dependiam do comportamento anterior.Portanto, você deve ter cuidado ao encapsular o que não deseja confiar, para que as classes derivadas obedeçam aos contratos definidos pela classe base.E uma vez que existem herdeiros, você tem que estar realmente cuidado com o que você muda na classe base.

Answer 4

Mais especificamente do que DaveK, geralmente significa que se você quiser adicionar funcionalidades adicionais ou alterar a funcionalidade de uma classe, crie uma subclasse em vez de alterar a original.Dessa forma, qualquer pessoa que use a classe pai não precisa se preocupar com alterações posteriores.Basicamente, é tudo uma questão de compatibilidade com versões anteriores.

Outro princípio realmente importante do design orientado a objetos é o acoplamento fraco através de uma interface de método.Se a alteração que você deseja fazer não afetar a interface existente, é bastante seguro alterá-la.Por exemplo, para tornar um algoritmo mais eficiente.Os princípios orientados a objetos também precisam ser temperados pelo bom senso :)

Answer 5

As entidades de software devem estar abertas para extensão, mas fechadas para modificação

Isso significa que qualquer classe ou módulo deve ser escrito de forma que possa ser usado como está, possa ser estendido, mas nunca modificado.

Exemplo ruim em Javascript

var juiceTypes = ['Mango','Apple','Lemon'];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}

exports.makeJuice = juiceMaker;

Agora se você quiser adicionar Outro tipo de Juice, você tem que editar o próprio módulo, dessa forma estamos quebrando o OCP.

Bom exemplo em Javascript

var juiceTypes = [];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}
function addType(typeName){
    if(juiceTypes.indexOf(typeName)==-1)
        juiceTypes.push(typeName);
}
function removeType(typeName){
  let index = juiceTypes.indexOf(typeName)
    if(index!==-1)
        juiceTypes.splice(index,1);
}

exports.makeJuice = juiceMaker;
exports.addType = addType;
exports.removeType = removeType;

Agora você pode adicionar novos tipos de suco de fora do módulo sem editar o mesmo módulo.

Answer 6

O princípio significa que deve ser fácil adicionar novas funcionalidades sem ter que alterar funcionalidades existentes, estáveis ​​e testadas, economizando tempo e dinheiro.

Freqüentemente, o polimorhismo, por exemplo, usando interfaces, é uma boa ferramenta para conseguir isso.

Answer 7

Uma regra prática adicional para estar em conformidade com o OCP é tornar as classes base abstratas em relação à funcionalidade fornecida pelas classes derivadas.Ou, como diz Scott Meyers, 'Torne as classes não-folha abstratas'.

Isso significa ter métodos não implementados na classe base e implementar esses métodos apenas em classes que não possuem subclasses.Então o cliente da classe base não pode confiar em uma implementação específica na classe base, pois não existe nenhuma.

Answer 8

Quero apenas enfatizar que "Aberto/Fechado", embora seja obviamente útil em programação OO, é um método saudável para usar em todos os aspectos do desenvolvimento.Por exemplo, na minha própria experiência, é um ótimo analgésico usar "Aberto/Fechado" tanto quanto possível ao trabalhar com C simples.

/Roberto

Answer 9

Isso significa que o software OO deve ser desenvolvido, mas não alterado intrinsecamente.Isso é bom porque garante um desempenho confiável e previsível das classes base.

Answer 10

Recentemente, recebi uma ideia adicional do que este princípio implica:que o Princípio Aberto-Fechado descreve ao mesmo tempo uma maneira de escrever código, bem como um resultado final de escrever código de maneira resiliente.

Gosto de pensar em Aberto/Fechado dividido em duas partes intimamente relacionadas:

• Código que é Abrir alterar pode alterar seu comportamento para lidar corretamente com suas entradas ou requer modificação mínima para fornecer novos cenários de uso.
• Código que é Fechado para modificação não requer muita ou nenhuma intervenção humana para lidar com novos cenários de uso.A necessidade simplesmente não existe.

Assim, o código que exibe comportamento Aberto/Fechado (ou, se preferir, atende ao Princípio Aberto/Fechado) requer modificação mínima ou nenhuma modificação em resposta a cenários de uso além daqueles para os quais foi originalmente construído.

No que diz respeito à implementação?Acho que a interpretação comumente declarada: "Open/fechado refere-se ao código polimórfico!" Para ser, na melhor das hipóteses, uma declaração incompleta.O polimorfismo no código é uma ferramenta para atingir esse tipo de comportamento;Herança, Implementação... na verdade, todo princípio de design orientado a objetos é necessário para escrever código que seja resiliente da maneira implícita neste princípio.

Answer 11

No princípio de design, SOLID – o "O" em "SOLID" representa o princípio aberto/fechado.

O princípio Aberto Fechado é um princípio de design que diz que uma classe, módulos e funções devem ser abertos para extensão, mas fechados para modificação.

Este princípio afirma que o design e a escrita do código devem ser feitos de forma que novas funcionalidades sejam adicionadas com alterações mínimas no código existente (código testado).O design deve ser feito de forma a permitir a adição de novas funcionalidades como novas classes, mantendo o máximo possível o código existente inalterado.

Benefício do Princípio de Design Aberto e Fechado:

1. A aplicação será mais robusta porque não estamos alterando a classe já testada.
2. Flexível porque podemos acomodar facilmente novos requisitos.
3. Fácil de testar e menos propenso a erros.

Minha postagem no blog sobre isso:

http://javaexplorer03.blogspot.in/2016/12/open-closed-design-principle.html