Principio Open/Closed – SOLID – OCP

solid-open-closed

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

solid-open-closed-classe-salario

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.

baixar-ebook-requisitos-de-software

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.

solid-open-closed-classe-salario-com-interface

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!

OCP