O Princípio OCP (Open/Closed Principle) é um princípio do SOLID.
O Princípio é de que no software, o código deve ser aberto para extensão, mas fechado para alteração.
Mas o que isso quer dizer? Vamos entender melhor neste post.
Todo software é dinâmico, evolui constantemente durante sua vida. Uma hora o software “morre”, torna-se obsoleto e para de evoluir. Geralmente é substituído por outro software.
Essa evolução se dá através da manutenção no software.
O problema de não usar o princípio Open/Closed
Muitas vezes usuários pedem uma alteração que conceitualmente é simples, mas tecnicamente é um grande problema, pois a arquitetura do software foi mal projetada e impede que coisas simples sejam facilmente implementadas.
Então, o desgaste inicia-se, onde o usuário defende que tem que ser feito rápido e com baixo custo, e o fornecedor defende que levará tempo e não será tão barato.
E isso é muito mais paradoxal do que parece, pois ambos estão certos em seus respectivos pontos de vista, mas provar aos dois lados que fora de seus pontos de vista estão equivocados é algo muito difícil.
Muito dessa dificuldade em implementar coisas conceitualmente simples tem como causa a implementação original ter sido feita com baixa qualidade. Princípios como o Open/Closed facilitam muito a manutenção de um software, mas demanda maior cuidado e tempo para ser implementado.
E o que temos no mercado, em muitas empresas, é uma visão de que o projeto tem que ser rápido e barato.
O OCP do SOLID
Basicamente, o OCP defende que cada “pedaço” de um software (classes, módulos, funções etc.) deve estar aberto para extensões, e fechado para alterações.
Estender é incrementar sem mexer no que está pronto, mantendo a estabilidade do software.
Alterar é incrementar mexendo no que está pronto, o que geralmente causa impacto no software.
A seguir, vamos exemplificar a aplicação do princípio.
Exemplificando
Temos uma classe de um sistema de folha de pagamento. A classe CalculoSalario possui um método CalcularSalario.
Este método é responsável pelo cálculo de salário, considerando a obtenção dos valores utilizados no cálculo, realização de cálculo de proventos, descontos, bases de cálculo etc.
No nosso exemplo, toda a lógica de cálculo de salário está dentro deste método.
Em função disso, qualquer alteração na forma de calcular salário demandará alteração neste método, pois toda a lógica de cálculo de salário está inserida num único ponto do sistema, e também. Se houver alteração na assinatura do método também haverá impacto, pois a classe CaculoSalario está exposta diretamente para outras classes realizarem instância dela.
O modelo apresentado não está adequado ao Open/Closed, e nem o suporta, pois obrigatoriamente está aberto para alteração (pois como a lógica está centralizada num único ponto, para evoluir o software é necessário alterar este ponto) e fechado para extensão (pois qualquer evolução vai impactar nos consumidores da classe).
Vamos evoluir um pouco o modelo.
Agora não temos somente uma Classe, temos também uma Interface que a Classe realiza.
Isso já viabiliza a aplicação do OCP, pois é possível estender a classe CaculoSalario sem necessariamente alterar os pontos do sistema que a instanciam, visto que agora temos uma Interface que ajuda a diminuir o acoplamento. Quem quiser acessar recursos da classe vai fazê-lo através da Interface, e não mais instanciando a classe.
Temos ainda uma alteração na assinatura do método CalcularSalario, agora ele é exclusivo para a interface ICalculoSalario, o que obriga ao seu consumidor implementar a interface, pois através de simples instância da classe CalculoSalario o uso do método não é mais possível.
Ao incluir a Interface e alterar a assinatura do método ganhamos diretamente na diminuição do acoplamento, isolando o método de cálculo do salário, favorecendo a extensão sem alteração (objetivo do OCP). E é possível evoluir a classe CalculoSalario sem impactar seus chamadores, que estão conectados na Interface.
A classe CalculoSalario está fechada para alterações, mas alterações no escopo podem ser feitas através da criação de novas classes (que realizarão a mesma interface), e aberta para extensões (novos métodos podem ser criados na classe sem causar impacto no que está pronto).
Concluindo
Poderíamos criar diversas variações do modelo, evoluindo muito além do exemplificado, mas o objetivo foi introduzir o princípio Open/Closed de uma maneira simples.
O OCP é muito eficiente quando atendido por padrões de projeto como *Factory (Simple Factory, Factory e Abstract Factory), Builder, Façade, dentre outros padrões estruturais/criacionais.
Abraço!