Generalizing dispatching in a distributed object system

Классические модели как правило опираются на понятие класса, выполняющего следующие роли: — общий исполняемый код; - общий интерфейс; - производство новых объектов, разделяющих общие ресурсы.

Типичные характеристики диспетчера классов: — каждый объект имеет класс; - классы обладают суперклассами, выстраивающимися в иерархию; в ответ на сообщение система ищет в иерархии классов соответствующий ему обработчик.

Кроме того, различные системы накладывают на эту схему свои специфические ограничения.

Dispatching родовых функций.

Иногда полезно рассматривать части заклинания не как приемник и аргументы. Hапример: (aShape 'draw aDevice) В этом случае конкретный исполняемый код зависит не только от aShape, но и от aDevice. Здесь вместо тупого выстраивания конструкции типа case целесообразно воспользоваться техникой кратного dispatching. В классической модели единственно определяющим аргументом является сообщение; соответственно, разумно объединить сообщение draw, посылаемое aDevice с различными вариантами aShape, например, drawRectangle. Это решение делает проблему выбора скрытой от диспетчера.

Соответствующий механизм называется родовыми функциями. Это группа методов, обеспечивающих сходную функциональность над множеством классов. draw есть родовая функция, описываемая как (defgeneric draw (aShape, aDevice)) (defmethod draw (aShape Rectangle) (aDevice X-Window) …) …

В DOS для реализации такого подхода требуется описание специального объекта — родовой функции; ее задача заключается в «регистрации» соответствующих частных методов; получив заклинание, диспетчер родовой функции направляет его тому или иному методу в зависимости от параметров. Hа языке DOS это описывается так: (DEFINE draw (GENERIC-FUNCTION (shape device)) (ADD-METHOD draw (shape device) (AND (is-rectangle shape) (is-X-Window device))) …

Так как мы не вправе пользоваться никакой предопределенной информацией об объектах, нам потребуется дополнить средства dispatching возможностью проверить принадлежность объекта классу и способность класса к выполнению конкретного заклинания.

Распределенные объекты.

Обмен сообщениями между компонентами распределенной по сети системы благодаря гибкому dispatching может быть реализован с помощью удаленных заклинаний не меняя базовой концепции DOS.

Модель клиент-сервер.

Данная модель совмещается с идеологией DOS следующим образом: клиент заклинает удаленный сервер (приемник). Hеобходимо выполнить две вещи: — расширить локальное понятие dispatching для вызова через сеть — построить объект, представляющий образ сервера в клиентской системе.

Диспетчер этого объекта должен выполнить следующие действия: — установить связь с сервером — перевести аргументы в допустимую для передачи форму — послать сообщение серверу — ждать ответа — перевести ответ сервера в формат локальной системы — закрыть соединение — вернуть ответ.

Подобный объект-образ должен инкапсулировать в себе информацию, достаточную для связи с сервером; таким образом, он отбирает «сетевую» часть диспетчеризации у клиента. Hапример, в TCP/IP этот объект описывается как TYPE NetObj = Obj. T OBJECT hostname: TEXT; portnum: CARDINAL; OVERRIDES dispatcher: = NetObjDispatcher; END Подобным методом реализуются и другие сетевые модели. Отдельно следует заметить, что при большом количестве объектов зачастую целесообразно присвоить им уникальные идентификаторы или индексы, хранящиеся отдельно от них самих.