Modularização /ou: Tudo sobre interesses e verdades...

Assim como eu, acredito que você, caro desenvolvedor, deve ter ouvido zilhares de vezes que software deve ser construído em módulos, componentes, bibliotecas ou qualquer outro nome para as subdivisões de código fonte. Isso levaria o software a ter maior qualidade. Mas na prática me parece contraditório. Já vi softwares com vários módulos e bibliotecas e isso não fizeram deles softwares bem construídos.

Mas e ai? Qual era o problema?

Pensando recentemente sobre o assunto, e armado agora com outros conceitos, vi que modularizar (componentizar, etc.) um software é o “como”, mas não o “porque”. Explico:

Pensando sobre isso vi que o “porque” da modularização é o que recentemente tenho visto por ai como “Separation of Concern” (Separação de Interesse) e “One Source of Truth” (Uma [única] Fonte de Verdade). Primeiro, Separation of Concern, é fazer com que o módulo, uma classe (no nível mais baixo) ou um serviço no modelo SOA (no nível mais elevado), seja responsável por um motivo único. Um sistema de recebimentos não deve ser responsável por controlar comissões, por exemplo. Assim como uma classe de business não deve saber como fazer uma chamada ao banco ou abrir um socket TCP/IP. E por ai vai...

E por que separar dessa maneira? Por um único motivo: One Source of Truth. Se a verdade, ou melhor, a maneira como faço algo, reside em apenas um lugar, de maneira atômica, eu posso mudar essa verdade e todos vão segui-la. Agora se tenho mais de uma maneira de fazer algo, qual delas é a verdadeira? Isso me lembra um professor que costumava dizer “se eu tenho um relógio eu sei que horas são, se tenho dois, já não sei mais”.

Por mais que Separation of Concern e One Source of Truth possa parecer redundante por se tratar de modularizacao, acho importante reforçar que o “como” é conseqüência do “porque”. Ou seja, os módulos que vi sendo construídos de maneira errada, com códigos duplicados, sem clara divisão de responsabilidade entre eles, estavam apenas fazendo o que lhes foi ensinado, que era modularizar, mas esqueceram de falar o porque fazer daquela maneira. E novos conceitos como “baixo acoplamento”, Inversion of Control ou Dependency Injection, etc. não ajudam a melhorar essa situação se o conceito básico não estiver lá.

Mas fazer modularização do zero usando Separation of Concern e One Source of Truth de maneira eficiente não é fácil. Não é fácil porque envolve a exclusiva capacidade humana de abstrair. E abstrair de maniera correta é uma tarefa tão difícil que não seria uma má idéia um cientista da computação ter 2 anos de filosofia na faculdade só para começar a ter boa capacidade de abstração.

Mas dá para fazer boa modularização sem quebrar a cabeça. Aprenda “patterns”. Design Patters, Enterprise Patterns, etc. Se a sua verdade absoluta não e estiver lá, pelo menos você sabe que alguém já errou por você.