Projeto Orientado a Componentes, parte II

Quando dizemos que componentes são por definição intercambiáveis estamos continuando uma longa tradição de bons projetistas de bons sistemas, cujo conjunto de características sempre integrará, por mais sofisticada a metodologia e/ou a nomenclatura, a aplicação da separação entre interface e implementação. [1]

Se a interface continua a mesma, podemos substituir a implementação sem perturbar o comportamento do sistema. Obviamente que o comportamento do sistema deve mudar de alguma forma, senão trocar a porcaria do componente não teria propósito. Esperamos, portanto, que erros sejam corrigidos (de modo que o sistema de fato funcione como deveria), ou que o desempenho aumente (de modo que o sistema funcione antes que eu caia no sono) ou sei lá.

Aplicávamos esta distinção já na era do projeto estruturado; e no projeto essencial; e no projeto orientado a objetos; e agora no projeto orientado a componentes e aplicaremos no projeto orientado a serviços quando finalmente este troço alcançar a plebe.

Em um sistema orientado a objetos, nós temos tipicamente dois elementos em evidência como detalhe de implementação: a estrutura de um objeto, e as instruções levadas a cabo por seus métodos. Nós queremos liberdade para alterar a estrutura de um objeto e queremos liberdade para alterar a instruções executadas por seus métodos. (Há mais por debaixo do pano, como sempre.)

Em um sistema orientado a componentes, um terceiro elemento surge ofuscando, como se fosse, os outros dois; o componente propriamente dito. Entendemos que um componente possui uma interface e uma implementação; sendo a implementação de um componente composta por inúmeras classes. Além disso, um componente é um artefato componente (heh) de um sistema implantado; é parte da definição de componente que este seja intercambiável por um outro, que implemente a mesma interface, em um sistema implantado -- em contraste com um tipo de substituição que exige recompilação.

Esta última restrição, quando posta no contexto dos sistemas operacionais reais, com seus linkers e loaders reais, nos trás à crux do problema de projeto orientado a componentes: a implementação de uma classe integrante de um componente absolutamente não pode depender de um detalhe de implementação de uma classe integrante de outro componente.

Observe que esta restrição não é exatamente uma novidade, já que bons sistemas isolarão módulos através de interfaces para aumentar a coesão e diminuir o acoplamento; porém, quando componentes entram na jogada, a metodologia exige uma restrição mais forte.

(De fato, esta restrição metodológica se torna uma impossibilidade tecnológica assim que os componentes são levados ao próximo estágio, passam a não mais morar no mesmo espaço de memória virtual, e começam a ser chamados "distribuídos" ou "serviços".) [2]

É por esta razão que os líderes do Projeto Spaghetti falharão em "componentizar" seu sistema; mesmo que, à primeira vista, seja possível seccionar sua estrutura de classes em artefatos binários distintos.

[1] Nós, filhos da cultura européia, nem escrevendo programas nos livramos da dicotomia corpo versus espírito. Nem imagino o que seria uma metodologia de desenvolvimento de sistemas desenvolvida por monges taoístas chineses.

[2] E portanto, domar a restrição metodológica significa poder conviver com a impossibilidade tecnológica e eventualmente programar os sistemas do futuro.