A uma das grande dificuldades hoje em dia em termos de  desenvolvimento de software, esta relacionada a manutenção. Segundo pesquisas, 80% do investimento feito em software está relacionado ao custo da manutenção.O fato de muitos softwares serem construindo sem boa práticas e padrões adequados, ou até mesmo, construídos sem uma sólida arquitetura; acaba por se ter um  produto mal feito, um verdadeiro “elefante branco”. Mais ai fica a pergunta: o que torna um software difícil de se evoluir ou manter? Além dos problemas citados anteriormente, o que ocorre, é que o código mal escrito faz com que uma pequena alteração cause outros erros, e isto quando ao solucionar um problema não surja outro. O padrão Open Close Princíple, um dos princípios SOLID, diz o seguinte: “Entidades de software ( classes, métodos, módulo, etc ) devem estar abertas para extensão, mas fechadas para modificação”.

     A afirmação acima, só pode ser mantida se o software tiver um design concebido sob os pilares das boas praticas de desenvolvimento de software, e isto incluir aplicar padrões e princípios que deem base para um softwares que tenha uma base sólida. Veja o exemplo abaixo, sem ter sido considerado o princípo do aberto/fechado:
 
 

     Veja que no código acima, temos muitos problemas de design. O principal é que, caso seja feita uma modificação no cálculo do salário, seja a inclusão de alguma fórmula adicional ou qualquer outro fator, pode causar comportamentos inesperados para quem usa esta classe, até mesmo um bug. Observe agora o cenário do exemplo acima, aplicando o Open Close Principle:

 

Diagrama
 
 
Exemplo de código:
 
 

     Note que no exemplo aciuma, a base não muda, ou seja, é fechada para modificação; passando assim ser de responsabilidade das classe herdeiras, implementarem o comportamento de acordo com um determinado cenário. Implementando um design de arquitetura, tendo em mente o princípio do aberto/fechado, o impacto das mudanças reduz drasticamente. Fazendo com que tenhamos um software flexível, robusto e aceita as mudanças, ao invés de brigar com elas. O exemplo acima deixa claro isto, e uma vez sendo alterado o cálculo do salário do analista, como o do gerente, a base se manter imutável diminuindo a possibilidade de bugs no sistema.

     Bom Pessoal, chegamos ao fim deste nosso artigo. Espero ter ajudado e contribuído de alguma forma para o crescimento profissional de cada leitor. Um abraço e até a próxima.