• 

  Rafael Camarda

• 13 de junho de 2018

O Open Closed Principle – Entendendo SOLID – Parte 2

Dando continuidade a nossa série de postagens sobre SOLID hoje falaremos sobre o Open Closed Principle. Se você não viu a primeira parte da nossa série, não deixe de ver aqui.

O segundo princípio, no original, diz que: “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.” Meio confuso não é mesmo? Como uma classe deve estar aberta para extensão mas ao mesmo tempo fechada para modificações?

De uma forma clara, o que o princípio quer dizer é que quando estamos estruturando nossos módulos, classes e métodos, quando uma nova funcionalidade é necessária, nós não deveríamos modificar nosso código mas sim sermos capazes de escrever novos códigos que possam ser usados pelos já existentes. Ao seguir o princípio, garantimos que o nosso código existe se mantenha claro, coeso e simples e ao mesmo tempo permitindo que nosso sistema evolua de forma saudável.

Existem diversas formas de atingirmos o que foi dito, seja através de herança/polimorfismo ou composição. Porém, ao usarmos herança podemos acoplar mal nosso funcionamento se não soubermos claramente o que estamos fazendo. Claro que o contexto é tudo, mas por via de regra, enquanto não trazemos um post aqui sobre quando usar ou não usar herança, vejamos um exemplo de como atingir o OCP utilizando composição.

O Open Closed Principle

Veja o exemplo abaixo. Imaginemos que possuímos uma transportadora que envia produtos para todo o Brasil por padrão via caminhões.

Nesse código bem simples, se o produto estiver pago, ele pode ser enviado e a classe TransporteCaminhao se encarregará disso. Porém, esse trecho de código fere o OCP por um motivo bem simples. Imagine agora que nossa empresa cresceu e está aumentando seu escopo. Além de fretes de longa distância, também enviaremos fretes curtas e agora além de caminhões também enviaremos através de motoboys.

Teríamos que ter condições dentro de nossa classe EnviarProdutos para fazer isso? Perceba que nossa classe não está aberta para extensão pelo fato de que nosso método padrão de envio está “hard-coded” dentro de nossa classe. Mas nem tudo está perdido! Podemos usar injeção de dependências resolvendo esse dilema e obedecendo assim o princípio.

Perceba que agora podemos ao usar nossa classe EnviaProdutos,  escolher qual é o método de envio e injetar essa dependência dentro de nossa classe, sendo que qualquer método de envio que seja criado daqui pra frente possa ser usado, desde que ele possua o método enviar. Cada classe agora permanece simples, coesa e o mais importante, extensível.

Sempre que adicionamos novos códigos, aumentamos o risco de bugs e comportamentos inesperados. Porém, ao usar o OCP nós diminuímos de forma significativa esse risco.

Espero que tenha ficado claro o que é o Open Closed Principle. Na semana que vem abordaremos o terceiro princípio, o Liskov Substitution Principle.

Deixe seu comentário! Críticas, dúvidas e sugestões são sempre bem vindas.

Algumas fontes utlizadas nesse post:

• https://medium.com/@tedtoer/open-closed-principle-in-ruby-examples-1a06bf6a4abaab
• http://rubyblog.pro/2017/05/solid-open-closed-principle-by-example
• https://code.tutsplus.com/tutorials/solid-part-2-the-openclosed-principle–net-36600
• http://joelabrahamsson.com/a-simple-example-of-the-openclosed-principle/
• https://codeburst.io/understanding-solid-principles-open-closed-principle-e2b588b6491f