OCP- Open-Closed Principle
Pelo nome ninguém conhece, porém, se falarmos o chamarmos pelo seu apelido carinhoso todo mundo conhece: “interface”. Ah! Aquela lá que aprendemos na academia? Agora que todo mundo já se lembrou mais ou menos do assunto, vamos consultar o Tio Bob. Ele sempre tem algo a nos dizer:
“… para que os sistemas de software sejam fáceis de mudar (…) o comportamento desses sistemas mude pela adição de um novo código em vez da alteração do código existente”.
Bah! Se ler um conselho assim já soa como um sonho, imagina se nós ouvíssemos se o Tio Bob estivesse ao vivo falando para nós. Eu creio que é o sonho de todo programador ter um software de fácil manutenção e que possa ser incrementado sem prejuízo ao que já está feito, certo? Vamos entender um pouco mais sobre este princípio “Aberto-Fechado” para avançarmos no mundo da programação. Segundo a máxima deste princípio devemos entender o que significa “extensão” no contexto do princípio, ou seja,
Um artefato de software deve ser aberto para a extensão, mas fechado para a modificação. (Beltrand Meyer, 1988)
Para facilitar vamos voltar um passinho atrás para entendermos melhor. Acredito que seja bastante providencial este retorno para nosso entendimento. Se voltarmos um pouco no tempo veremos que este princípio veio para resolver um problema comum de dependência de código. O que isto significa?
No passado nós tínhamos muito código acoplado, ou seja, código que dependia de hardware ou mesmo de outro código para funcionar e isto tornava o desenvolvimento e manutenção muito difíceis, afinal, sempre que surgia uma nova tecnologia ou uma nova ferramenta muito código deveria ser reescrito. O problema é o seguinte:
“…quando extensões simples nos requisitos forçam mudanças massivas no software, os arquitetos desse sistema de software estão em meio a um fracasso espetacular. (…) Uma boa arquitetura de software deve reduzir a quantidade de código a ser mudado para o mínimo possível. Zero seria o ideal”.
Como é possível organizar uma arquitetura “extensível”? Esta guinada para o uso de uma interface foi uma virada radical construída a duras penas. Antigamente a tecnologia mudava de tempos em tempos, portanto, muitos programas levavam anos ou até mesmo décadas para se tornarem obsoletos frente aos problemas que resolviam. Hoje, tudo muda em questão de minutos ou até mesmo segundos. Quando uma nova ferramenta é inventada em questão de pouco tempo ela será conhecida no mundo todo.
O que ocorreu aqui foi uma mudança radical de inversão de dependência. O próprio Tio Bob faz uma reconstituição histórica trazendo a história da substituição dos cartões perfurados para as fitas magnéticas. O que mudou? Mudou a concepção de dependência de código de máquina! Lembram que o sonho do programador é alterar o comportamento de uma máquina através de um programa? Foi pensando justamente nisso que…
“…no final da década de 1950, aprendemos que os nossos programas deveriam ser independentes dos dispositivos. Por quê? Porque tivemos que escrever vários programas dependentes dos dispositivos para só então descobrir que realmente queríamos que eles fizessem o mesmo trabalho em um dispositivo diferente”.
A “mágica” segundo Tio Bob é conhecida dos mais antigos…se fizermos a inversão de dependência de uma implementação para a dependência de abstração será possível realizar as alterações em um programa sem ter prejuízo ou quebras, ou seja, não precisaremos alterar códigos existentes e poderemos incrementar nosso programa com segurança.
É claro que este artifício é antigo, porém, nas linguagens orientadas a objeto teremos facilidade, segurança e agilidade no tratamento de novas funcionalidades. Se antes quase sempre estivemos atuando na abstração das relações entre programa e máquina, agora poderemos abstrair qualquer parte de nossos sistemas, pois,
O fato de que linguagens OO oferecem um polimorfismo seguro e conveniente significa que qualquer dependência de código fonte, não importa onde esteja, pode ser invertida.
E a grande maravilha da Orientação a Objetos fecha com coesão e baixo acoplamento com o sonho de todo programador, de todo empresário, de todo mundo que trabalha com programação:
A Orientação à Objetos é a habilidade de obter controle absoluto, através do uso do polimorfismo, sobre cada dependência de código fonte do sistema.
E a pergunta que segue logicamente é a seguinte:
Por que a interface tem uma posição tão privilegiada? Porque contém as regras de negócio. (…) Observe como isso cria uma hierarquia de proteção baseada na noção de “nível”. Por serem de nível mais alto, as interfaces são as mais protegidas.
No final das contas, todos nós deveríamos aprender pelo amor a utilizarmos interfaces o tempo todo para deixarmos explícitas nossas intenções futuras especialmente em alguns pontos críticos de nossos sistemas. Isso não quer dizer que nós poderíamos cometer exageros.
Foi pela dor da alteração de um código existente que foi possível iniciarmos este processo de abstração para extensão sem alterarmos nossos códigos. E, além de facilitar nossas ações e a interação entre atores/contextos em nossos sistemas, esta nova postura nos trouxe a possibilidade de termos controle absoluto de tudo que fazemos.
No final das contas este princípio deve ser tratado como uma maravilha da inteligência humana: agora temos controle, podemos trabalhar juntos em projetos, podemos literalmente escrevermos código a quatro mãos sem nos preocuparmos com uma direção de dependências.
Agora, literalmente, nós atuamos como pilotos de nossos códigos. Nossa tão sonhada facilidade de alteração de código começa a tomar corpo sem um grande impacto na adição de novas mudanças. Nossos softwares começam a se tornar mais robustos, com fácil manutenção, melhorias e implementações mais fáceis de se fazer com o mínimo de recurso humano envolvido.
O OCP é uma das forças motrizes por detrás da arquitetura de sistemas. Seu objetivo consiste em fazer com que o sistema seja fácil de estender sem que a mudança cause um alto impacto.
Finalmente, o que se pretende com o conceito de interfaces é garantir o controle da direção das dependências. Com este princípio iniciamos um novo capítulo na história do desenvolvimento de sistemas: agora somos capazes de escrever códigos coesos com controle total da direção que queremos seguir, ou seja, temos o poder de decisão em nossas mãos para iniciarmos nossas arquiteturas com separação de tarefas, coesão entre classes de diferentes atribuições sem quebrar nossos softwares facilmente.
Não importa o que você faça, sempre lembre do seguinte: Seu sistema pode ser incrementado sem alterar o que já está implementado? Se sua resposta demorar, presumo que poderemos melhorar a aplicação deste princípio. E se, mesmo à luz do OCP, der errado? Não há problema, vamos entender o erro e melhorarmos nossa análise. Importante é progredir com soluções fáceis para atendermos nossos atores. Comece pelo simples e evolua. Simples!
Nos vamos em nossa próxima publicação!
Deseja conversar mais sobre o assunto? Você me encontra aqui!
https://www.linkedin.com/in/alexandre-klock-ernzen-5484319/
Artigos sobre SOLID:
Introdução > https://medium.com/@bracinho2/solid-introdu%C3%A7%C3%A3o-6b4dbdacdb87
S > https://medium.com/@bracinho2/srp-single-responsability-principle-8d9a68bbae76
O > https://medium.com/@bracinho2/ocp-open-closed-principle-cc21cb168707
