A programação da aplicação processa-se sem grandes alterações do código original, em relação ao que seria de esperar se não se fizesse uso da funcionalidade adicional. Mais importante: as alterações ao código são mínimas e localizadas, envolvendo apenas manipulações da interface das classes. As ferramentas a utilizar não precisam, assim, de ser tão complexas como um compilador da linguagem, hipoteticamente utilizado para realizar a mesma função.
Os mecanismos de aumento de funcionalidade dos objectos são ortogonais às suas outras características, i.e., não é importante a natureza de um objecto do programa, para que lhe seja associada funcionalidade adicional.
O aumento de funcionalidade é transparente, i.e., não interessa ao
código do nível da aplicação saber como funcionam os mecanismos de
baixo nível que a suportam. Há, no entanto, que ter em conta que
certos aspectos não podem ser inteiramente transparentes. É o caso da
activação dos serviços: tem que ser o nível do programa a tomar
decisões de alto nível, como decidir quando um objecto sob o seu
controlo passa a usufruir de determinada característica. Por exemplo,
deve ser a aplicação a decidir quando um objecto deve ser exportado.
Um objecto não é exportado expontâneamente
.
A aparente perda de transparência não se reveste de especial importância, já que está muito bem delimitada (pode reduzir-se a uma linha de código, e.g. a invocação de um gestor de módulo), e pode ser feita de forma a não envolver o restante código da aplicação.
A transparência na programação é maior que em qualquer dos casos apresentados no capítulo 2, pois as entidades com que o programa lida não são distinguidas das que estão a substituir. Isto não se passava com a herança, onde a substituição de um objecto de uma classe por um de outra era sempre vista e controlada pela aplicação. Os smart pointers e acessores oferecem uma forma limitada de transparência e apresentam problemas relacionados com o facto de as entidades com que a aplicação lida não terem suporte da linguagem para os papéis que desempenham (ponteiros e referências para objectos, respectivamente).
O modelo com envelopes e cartas aproxima-se mais do que é descrito na secção 2.2, mas consegue uma maior transparência na programação, pelo facto de a aplicação não saber que os envelopes são representantes de outra entidade.
O sistema Open C++ é um exemplo de sistema utilizando herança, mas de forma diferente dos anteriores. Embora a aplicação veja a mudança de classes utilizadas quando quer criar objectos, não vê a programação que leva à criação das novas classes, pois existe uma ferramenta que dá suporte à programação. As desvantagens situam-se na área da escrita e processamento do código da aplicação: a linguagem utilizada é C++ em que alguns comentários são significativos, i.e., contêm código para a ferramenta, implicando a alteração da sintaxe da linguagem e a existência de uma ferramenta mais complexa que o pretendido.
No modelo proposto procurou-se gerar todo o código necessário a cada função apenas com base na análise da interface de cada classe e no estebelecimento e cumprimento de certas normas para activação do código automático. Este actua como forma de controlo do comportamento dos envelopes, que actuam como simulacros das cartas junto do restante código da aplicação (na interacção com o nível de programa). A forma de geração é conseguida de forma mais simples que em qualquer dos casos anteriores, para funcionalidade equivalente.