O nível de ligação existe como forma de virtualizar os acessos aos serviços fornecidos pelo nível de suporte, constituindo a interface de um módulo funcional. Neste nível existem vários objectos de ligação com os quais a aplicação pode dialogar e outros que, não estando acessíveis à aplicação, providenciam um nível adicional de indirecção na comunicação com o nível inferior.
Os objectos do nível de ligação com que a aplicação pode dialogar são os envelopes, existindo um em cada objecto composto, e os gestores de módulos funcionais, com os quais o código da aplicação deve dialogar para conseguir activar características especiais associadas a um objecto.
Pode argumentar-se que, ao prever o contacto entre o nível de programa e os gestores de módulos, se está a introduzir na aplicação uma forma não transparente de funcionamento. Este facto não é, porém, de grande importância. Tem que ser o código do nível de programa a decidir, e isso não pode ser feito transparentemente, quando uma característica deve manifestar-se para um dado objecto.
O contacto com os gestores é apenas uma das formas possíveis de comunicar uma decisão do nível de programa ao nível de ligação. Outra forma seria, por exemplo, a introdução de métodos adicionais nos envelopes. Esta última forma é, no entanto, funcionalmente equivalente à primeira e não torna o processo mais transparente. Os métodos a invocar não pertenceriam ao objecto de programa original (sem envelope), implicando, assim, que o nível de programa tenha que distinguir entre as noções de objecto de programa e de objecto de ligação, representante daquele. O código seria menos limpo.
A existência de métodos adicionais nos envelopes não fica excluída devido às razões enunciadas acima. Antes pelo contrário, a existência de tais métodos é muito útil ao funcionamento automático dos gestores. A interface adicional fica assim, não para ser utilizada pelo nível de programa, mas sim pelos outros níveis, que utilizarão os métodos correspondentes como upcalls [Clark, 1985]. O facto de se terem métodos adicionais não perturba a aplicação porque ela não vai precisar de saber que eles existem. Quem os utiliza é quem os define, i.e., o módulo funcional em causa.
A definição da interface adicional será da responsabilidade do programador de serviços. O programador da aplicação ao escolher o módulo associado a uma dada característica especial de um objecto, especifica automaticamente quais os métodos a adicionar à interface do envelope associados a esse objecto. O capítulo 4, para o último caso, e o capítulo 5, para o primeiro, discutem alguns aspectos da especificação da interface adicional dos envelopes.
Os outros objectos do nível de ligação, que não são nem envelopes, nem gestores de módulos, não têm grande interesse para a discussão acima, pois não fazem parte da interface de um módulo funcional. Estão no nível de ligação porque são independentes dos objectos manipulados pelo módulo funcional, o que pode não acontecer com o código do nível de suporte, e porque podem ter que contactar outros objectos do nível de ligação, e.g. envelopes, para tomarem decisões de controlo. A função destes objectos é ajudar à gestão interna do módulo e garantir que um módulo possui um grau de autonomia elevado em relação ao código do programa.
Existem várias questões a resolver no nível de ligação. Os problemas que se apresentam nestes casos são vários e dividem-se em dois grupos: os dos envelopes e os dos gestores de módulos.
Os problemas que podem ser associados aos gestores de módulos são somente de ordem funcional, estando relacionados com as funções que desempenham dentro de um módulo. O estudo destes problemas fica melhor enquadrado na descrição de um módulo que de forma abstracta, ficando, assim, relegado para o capítulo 5.
Os problemas dos envelopes, além de funcionais, estão também relacionados com a estrutura do programa, pois eles são utilizados para substituir alguns objectos de programa. Os problemas funcionais estão relacionados com os níveis inferiores e prendem-se com o acesso a informação local, e.g. identificação de tipos. Os problemas estruturais devem-se à responsabilidade de cada envelope em garantir que o processamento se faz como se eles não existissem: devem garantir correcto despacho de métodos, i.e., seleccionar correctamente o método a executar, numa hierarquia de classes; devem assegurar correcto funcionamento na presença de conversões de tipos; e funcionar correctamente no caso de se ter herança múltipla.
Os problemas relacionados com a geração de envelopes e código adicional serão vistos em pormenor, primeiro, no capítulo 4, relativo à discussão da funcionalidade das ferramentas; depois, no capítulo 6, quando se apresentar a realização concreta dos mecanismos de suporte.