SOLID — Open Closed Principle (OCP)
Dando continuidade aos nossos estudos sobre SOLID, neste artigo vamos aprender um pouco mais sobre o segundo princípio conhecido como OCP (Open-Closed Principle). Se você perdeu o primeiro capítulo sobre SRP (Single Responsibility Principle), aconselho que você leia o mesmo pois ele é a base para os demais princípios e para uma boa escrita de código.
OCP — Open Closed Principle
Também conhecido como princípio do aberto-fechado, ele determina que um objeto ou entidade deve estar aberto para expansão, mas fechado para modificação, ou seja, quando novos comportamentos e recursos precisam ser implementados ao software, nos devemos estender nossas classes e não alterar o código fonte original.
Exemplo prático
Veremos logo abaixo três classes, sendo duas delas, classes de banco (instituição financeira) e uma classe específica para geração de boletos de cobrança bancária.
Repare que a classe TBoleto precisa verificar o banco em questão, para efetuar a geração do boleto. Supondo que seja necessário realizar a geração do boleto bancário para mais um banco, obviamente seria necessário modificar essa classe! Sendo assim, estaríamos quebrando o princípio Open-Closed do SOLID.
Vinicius, mas qual o problema de se alterar a classe TBoleto?
Não seria mais fácil apenas acrescentar mais um ELSE IF e verificar o novo banco aplicando as respectivas regras? Sim, e provavelmente essa seria a solução que programadores menos experientes iriam fazer. Mas, esse é exatamente o problema! Alterar uma classe já existente para adicionar um novo comportamento, corremos um sério risco de introduzir bugs em algo que já estava funcionando.
Lembre-se: OCP preza que uma classe deve estar fechada para alteração e aberta para extensão.
Então, como vamos adicionar um novo comportamento sem alterar o que já existe?
Basicamente o que precisamos fazer é separar o comportamento extensível (gerar boleto) em uma interface e inverter as dependências. Se as separações forem bem definidas, logo nosso software estará aberto para extensão.
Refatorando nossas classes
Voltando para o nosso exemplo, podemos concluir que o contexto que estamos lidando é a geração de boleto de cobrança bancária. Aplicando as premissas de se isolar o comportamento extensível, podemos criar uma interface com o nome IBanco contendo o método GerarBoleto, e fazer com que nossas classes de bancos implementem essa interface. Além disso, iremos colocar as regras de geração do boleto dentro de suas respectivas classes, usando o método GerarBoleto, fazendo com que a classe TBoleto dependa somente da interface IBanco que iremos criar.
Veja o código refatorado abaixo:
Observe que agora a classe TBoleto não precisa mais saber qual é o banco para gerar o boleto. Ela será capaz de gerar o boleto de forma correta, independente do banco passado como parâmetro e sem qualquer necessidade de alteração do seu código fonte, desde que este implemente a interface e IBanco. Dessa forma, acabamos de implementar o princípio de OCP do SOLID em nosso código!
Nota: o Open-Closed Principle é base para o padrão de projeto strategy
Conclusão
Particularmente este é o princípio que mais me chama a atenção, pois a sua principal vantagem é a facilidade na adição de novos requisitos, diminuindo as chances de introduzir novos bugs, visto que o novo comportamento fica isolado, e o que estava funcionando continuara funcionando.
Código fonte: GitHub
Referências: Clean Code (Uncle Bob), Design Principles and Design Patterns, Wikipedia e O que é SOLID
