S.O.L.I.D na prática: Open/Closed Principle (OCP)

Neste post veremos o Princípio Aberto-Fechado, ou traduzindo, Open/Closed Principle (OCP), que corresponde a segunda letra do acrônimo SOLID. Trata-se do terceiro post da série sobre os 5 princípios SOLID.

O que é o Open/Closed Principle (OCP)?

O Open/Closed Principle, foi originalmente cunhado por Bertrand Meyer, e depois foi integrado ao SOLID. Ele diz que:

Um artefato de software deve ser aberto para extensão, mas fechado para modificação

De modo mais simples também podemos entender que o software (ou parte do software) deve aceitar novas funcionalidades, mas também deve ter uma parte fechada para alterações estruturais, o que na prática, significa, estar mais protegida contra mudanças de código.

Podemos então aplicar esses conceitos para guiar o design de classes (módulos) da nossa aplicação, incluindo algumas restrições em nossas classes. No entanto, a intenção por trás do OCP não é impor restrições mas sim permitir a adição de funcionalidades de uma forma mais flexível e segura.

Se você ainda não tinha se deparado com esses conceitos, em um primeiro momento pode parecer contraintuitivo, mas o ponto é que ao estabelecer uma base de código organizada, coerente e com as restrições certas, com o tempo você certamente também terá ganhos de produtividade sempre que for acrescentar novas funcionalidades e evoluir o projeto de software.

OCP aplicado a Classes

Questões para validar adequação ao OCP

Uma pequena dica é utilizar perguntas chave, como as 3 a seguir, para nortear a aplicação do OCP em casos de estruturação de classes:

• Ao usar herança, suas classes permitirão um reuso eficiente e flexível? (ou frequentemente será necessário alterar a classe base!?)
• Ao alterar uma funcionalidade em sub-classes precisarei alterar também a classe base ou outras funcionalidades? (se sim, é um sinal que você precisa rever o código)
• Ficará mais fácil adicionar novas funcionalidades ao código existente? (ou terei que “rebolar” sempre que houver uma alteração 😀 )

Acredito que isso ficará mais claro com os exemplos a seguir.

Insight: Proteção + Extensão

Para ilustrar melhor o racional sobre Proteção + Extensão por trás do OCP, podemos pensar em aplicações reais bastante conhecidas tais como:

• Navegador e suas extensões:
  • Um software como um navegador, como o Google Chrome por exemplo, tem seu core de funcionalidades fechado para modificações de externas. Apenas um número reduzido e bem delimitado de pessoas da empresa fornecedora do software conseguiram alterar esse “core” de funcionalidades e por razões muito específicas. Por outro lado o suporte a extensões (ou add-ons) de desenvolvedores de terceiros complementam as funcionalidades básicas (padrão) do navegador. Portanto, em relação a esses terceiros, podemos dizer algo como: “o navegador é aberto para extensão, mas fechado para modificação (terceiros não conseguem modificar a base);
• Aplicativos e Plugins de terceiros
  • Outro exemplo são os aplicativos de comunicação como o Teams ou o Discord, que também tem suas funcionalidades básicas de comunicador, chat, etc., mas ainda assim podem fornecer ainda mais “poderes” aos usuários através de diversos plugins, como ferramentas de votação, enquetes, comandos e ferramentas de IA, ferramentas do tipo Office para lidar com formulários e arquivos , integrações através de webhooks para notificações, etc.;
  • Uma pequena menção honrosa aqui ao software Winamp e vários outros apps da época! 😀 …que desde dos primórdios já implementavam essa ideia de plugins para “expandir seus poderes”.

Vídeo sobre OCP do canal

Se quiser entender melhor sobre as principais motivações de compreendermos estes princípios e ter a visão geral sobre essa série de posts, acesse o primeiro artigo da série pelo link a seguir:

Clique aqui caso queira acessar o primeiro post da série sobre SOLID