Esse não é mais um post sobre Lei de Deméter

A sílaba tônica é a primeira: pronuncia-se “Dí”meter.

Buzzword é moda: a todo momento surgem tecnologias para você entregar sua aplicação serverless, novas metodologias de escalar sua aplicação na nuvem, maneiras de quebrar seu monolito em microserviços escaláveis, e por aí vai.

Várias buzzwords são úteis: mas muitas outras também não. Muitas ficam legais na talk mas nem todas no dia a dia, certo?

Tem uma buzzword específica que já perdura por uns trinta anos, e continua sendo discutida e utilizada. Mas como prometido: esse não é mais um post falando sobre o que é a Lei de Deméter.

Década de 80: duas pessoas na Northeastern University completam um paper chamado “Garantindo o bom desenho de programas Orientados a Objetos”, que depois acaba por ser publicado via IEEE também. Nome legal, certo?

Essas duas pessoas eram os professores Karl Lieberherr and Ian Holland, e trabalhavam dentro do Deméter: um misto de projeto e pesquisa que propôs uma série de estudos e ferramentas a respeito do paradigma Adaptativo e Orientado a Aspectos.
Lembrando que no final dessa década o paradigma de programação Orientado a Objetos estava ganhando cada vez mais espaço, como uma outra opção a programação procedural, que se provava, em geral, pouco legível, adaptável, e por consequência, com maior custo de manutenção. Talvez seja parecido com o hype de programação funcional que já vem de quase uma década hoje, mas por diferentes motivos.

Nesse paper, eles descrevem a depois famosa Lei de Deméter: uma técnica agnóstica a linguagens de programação, que foi criada, refinada e usada pelo time do Deméter enquanto estavam criando aquelas ferramentas, e como esta ajudou a manter o código modular, encapsulado, e como um certo legado foi modificado para atender aos requisitos dessa técnica.

Mas porque o nome do time era Deméter?

Esse time, antes do projeto, trabalhava em uma linguagem de descrição de hardware chamada Zeus, e agora olha onde estamos indo: na mitologia Grega, Deméter e Zeus são os dois filhos de Cronus e Rhea, e também pais de Perséfone. Enquanto o time trabalhava em uma ferramenta para simplificar a linguagem, o pessoal queria simplesmente um nome relacionado a Zeus (e adivinha?) e Deméter foi escolhido como nome.
Recapitulando aquela parte da mitologia que ninguém ̶d̶á̶ ̶b̶o̶l̶a̶ lembra: Deméter é a deusa grega da Agricultura e da Distribuição, e mais para o fim do projeto, o nome acabou sendo promovido a ter a conotação de que um software criado usando essa Lei como um guia cresce, não é construído.

É incrível como uma simples ideia (“vamos diminuir duplicação e acoplamento de código”), um comportamento (“que tal arriscar e usar essa ideia nova?”) e um guia de estilos (modelagem que torna esse comportamento algo rotineiro) se tornou algo por si só. E é uma buzzword que vingou: já se passaram quase trinta anos e a Lei de Deméter continua por ser citada, e não, ela não é só sobre ter mais de dois pontos em chamadas de objetos.

Esse artigo é uma adaptação livre de um texto já publicado em Inglês, também de minha autoria. Opiniões apresentadas tanto nesse quanto no texto original são também pessoais.

Referências: paper, IEE article, Professor Karl page, university project site

Tem interesse em trabalhar conosco? Nós estamos sempre procurando por pessoas apaixonadas por tecnologia para fazer parte da nossa tripulação! Você pode conferir nossas vagas aqui.