O modelo de programação proposto por Guedes para o MSM, utilizando C++, veio substituir o anterior modelo, baseado em MachObjects. No novo modelo considerado existem objectos passivos que podem ser invocados transparentemente em relação à sua localização e todos os objectos são potencialmente persistentes. É proposto um modelo de separação de interfaces e suas concretizações (código) e um conjunto de construções linguísticas e rotinas de suporte que permite aos programadores construir aplicações distribuídas complexas.
A definição da interface entre os objectos é considerado um dos problemas fundamentais do modelo computacional de um sistema distribuído, onde é necessária a expressão de aspectos relacionados com o envio e recepção de informação entre contextos distintos.
O desafio, identificado para um sistema que ofereça transparência em relação à distribuição, é conseguir uniformizar a definição das interfaces de forma que ele funcione tanto com objectos locais como objectos remotos. Além das anteriores, existe a restrição de não modificação do compilador de C++ (a linguagem usada para especificar e codificar o sistema).
O modelo de separação baseia-se na utilização de herança múltipla para o estabelecimento da relação entre as classes que definem a interface e as que fornecem o código. A herança é utilizada com dois fins: permitir a especialização de interfaces; permitir a utilização de código (reutilização). Guedes advoga o uso de herança múltipla [Guedes, 1994, Capítulo 3,] como forma de remediar a deficiência que existe em C++ no tratamento da separação entre interfaces e código de suporte a essas interfaces, i.e., em C++ não se faz nenhuma distinção entre uma interface abstracta, que se limita a definir o conjunto de operações passíveis de serem executadas por um objecto (interface), e o conjunto de métodos que executam essas operações (declaração da classe).
Figure: Uso de herança múltipla no MS Mach.
Consegue-se, ao utilizar este método, dividir a estrutura de classes em dois grandes grupos: classes abstractas, que providenciam a interface; e classes concretas, que providenciam o código. Para que a descrição seguinte não se torne incompreensível, considere-se o exemplo da figura 2.1. Uma classe concreta X1, a partir da qual se vão criar objectos, deriva da abstracta X. Se, porventura, se quiser especializar a classe abstracta original, deve ser criada uma sua subclasse, também abtracta ( Y). A nova interface chega ao código do programador, tal como anteriormente, através de uma subclasse concreta ( Y1) da nova classe abstracta. A nova subclasse concreta deve também derivar da classe concreta X1, correspondente à classe abstracta X que é superclasse da classe abstracta Y, da qual é uma concretização. A razão da múltipla herança deve-se à necessidade de, além da nova interface, herdar o comportamento anterior.
Na figura 2.1, X2 e Y2 representam concretizações alternativas a X1 e Y1, para a mesma hierarquia abstracta. Em qualquer dos casos, o código contém referências somente para X e Y, sendo as instâncias criadas a partir de uma das classes concretas.
Um problema desta aproximação é não ser ser completamente transparente
na programação. Esta deve ter em conta que os objectos a manipular são
elementos das subclasses e não da superclasse abstracta. Assim, deve
existir uma terceira entidade capaz de tomar decisões acerca da
criação de objectos, não bastando instanciar uma classe
qualquer
. O facto
anterior vem despoletar outro problema: o código não permanece
inalterado, ou seja, o programador deve incluir no seu código
conhecimento de mais baixo nível. No caso particular do MSM,
tratando-se de programação de sistema e não de aplicações, poderia
argumentar-se que a contaminação do código se reveste de importância
menor do que aquela que teria para uma aplicação fora do sistema
operativo. Contaminação deve ser entendida como sendo
introdução de código de controlo que não está directamente relacionado
com a finalidade do programa.