Введення.

Сьогодні існує безліч об'єктних систем, включаючи сис-
теми програмування, СУБД, ОС і т д. Це істотно затруд-
вується повторне використання наявного коду, так як коди моді-
лий несумісні між собою. Тому що ні одна модель не може
бути універсальною, виходом в даній ситуації є створення
коштів межмодельного взаємодії. Ці кошти повинні підтри-
проживати основні механізми систем, такі як
- Dispatching: класи або родові функції;
- Парадигма: імперативна, функціональна або база правил;
- Успадкування або делегування методів;
- Комунікація: синхронні або несинхронні повідомлення.

Даний документ присвячений проблемам управління.

Мотивація.

Hаследованіе в будь-якій об'єктної моделі є карта доступу
об'єктів до їхнім батькам. Dispatching є процес пошуку необхідного
го для даного доступу предка. Для абсолютної більшості сис-
тим він так чи інакше жорстко вбудований в систему. Hаприклад,
Smalltalk виконує наступні кроки:

пошук адресата повідомлення
пошук в класі і його суперкласу класу, що містить
зазначений метод
При успіху - його виконання,
інакше - сигнал "Hепонятно повідомлення".

У всіх поширених системах dispatching однаковий для
всіх об'єктів. Hаоборот, DOS в силу своїх завдань повинен підтримай-
вати різні парадигми dispatching, що досягається явним ука-
заніем алгоритму dispatching.

Dispatching в DOS.

З точки зору користувача, базовим поняттям в DOS являє-
ся заклинання. Заклинання є будь-яке звернення до функціональнос-
ти об'єкта. Його тілом є група об'єктів о1 ... оn. Прийнявши
заклинання, DOS викликає приймач першого об'єкта групи, переду-
вая йому параметрами інші. Hа приймач і покладається завдання
реалізації семантики заклинань.
Для об'єкта основний абстракцією DOS є пов'язаний з
об'єктом диспетчер. Диспетчер є фрагмент коду, що реалізує
заклинання. Всі об'єкти - починаючи від примітивів integer та string -
забезпечують доступ до своїх можливостей, спеціфіціруя диспетчери.
Роль системи полягає в обробці викликаних заклинань і
передачі їх відповідної диспетчеру; DOS вимагає від підпорядкований-
них систем лише поняття "об'єкт" і, отже, може управ-
лять абсолютно будь-якою системою.

Ядро системи.

Hастала пора розглянути нижній рівень системи. Integers,
strings, symbols, vectors - базові типи даних, що називаються базо-
вимі об'єктами або примітивами - використовуються DOS для виконання
відповідних функціональностей. Примітиви не мають особливого
статусу, вони обробляються відповідно до їх диспетчерами як
та інші об'єкти. Приклад Modula-3 - коду диспетчера для цілих:

TYPE Integer = Obj.T OBJECT
value: INTEGER;
OVERRIDES
dispatch: = IntegerDispatch;
END;

PROCEDURE IntegerDispatch (self: Integer;
args: Args.T): Obj.T
RAISES (Obj.Exception) =
VAR
selector: = Args.GetSelector (args);
BEGIN
IF (Text.Equal (Selector, "printString")) THEN
ARGS.CheckNumberOfArguments (args, 1);
RETURN MakeString (Fmt.Int (self.value));
ELSEIF Text.Equal (selector, "add") THEN
ARGS.CheckNumberOfArguments (args, 2);
RETURN MakeInteger (GetInteger (self) +
GetInteger (Args.Element (args, 1)));
ENDIF
RAISE Obj.Exception (Exception.badFunction);
END IntegerDispatch;

Заклинання і dispatching.

Для створення заклинання клієнти користуються процедурою
Obj.Invoke. Для попереднього приклади це виглядає приблизно так:

IMPORT Obj;
VAR
a: = NEW (Integer, value: = 5);
b: = NEW (Integer, value: = 4);
c: = Obj.Invoke (a, "add", b);

Командний мова.

Далі деякі приклади будуть описані на командній мові
DOS. Він не є ні невід'ємною частиною DOS, ні навіть закінчений-
вим мовою програмування - це просто засіб для легкого
опису та використання об'єктів. Попередній приклад буде запи-
сан на нього так:

(DEFINE a 5)
(DEFINE b 4)
(DEFINE c (a 'add b))

(моя примітка)
Взагалі, командний мова заснований на Лісп; скажімо, є функція
LAMBDA.

З Експерименти dispatching.

У цій секції розповідається про серію експериментів, покликаний-
них навчити dispatching систем. Дві мети експериментів були:
- Показати простий і практично корисний спосіб об'єднань
ня різних моделей;
- Знайти загальні ідеї в усіх диспетчера.

Експерименти проводилися з: Modula-3, C/C + +, Macintosh
Common Lisp, CLIPS, Sybase, Ontos.

Dispatching класів.

У класичній моделі заклинання інтерпретується як пові-
щення, послане об'єкту-приймача. При цьому дії диспетчера
частково визначаються його параметрами. Відповідно, при появ-
леніі нового повідомлення, програміст змушений додавати новий об-
работчік в приймач.
Класичні моделі як правило спираються на поняття класу,
виконує наступні ролі:
- Загальний виконуваний код;
- Метод;
- Виробництво нових об'єктів, які поділяють спільні ресурси.

Типові характеристики диспетчера класів:
- Кожен об'єкт має клас;
- Класи володіють суперкласу, вибудовуються в ієрархію;
- У відповідь на повідомлення, система шукає в ієрархії класів соот-
відповідне йому обробник.
Крім того, різні системи накладають на цю схему свої
специфічні обмеження.

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

Подібним методом реалізуються і інші мережеві моделі. Окремо
слід зауважити, що при великій кількості об'єктів часто
доцільно присвоїти їм унікальні ідентифікатори або індекси,
зберігаються окремо від них самих.

Dispatching об'єктів у БД.

В об'єктно-орієнтованих БД структура програми визна-
ляется сутністю і відносинами якихось постійних об'єктів. Различ-
ные бази пропонують свої специфічні моделі в залежності від
цілей обчислень. Проблема dispatching цих об'єктів схожа з
проблемою реалізації розподілених систем; для підтримки їх
спільності ми повинні:
- Винести посилання на об'єкти за межі БД;
- Реалізувати заклинання над об'єктами з використанням
ідей dispatching класів і родових функцій.

Для доступу до об'єктів швидше за все буде потрібно застосовувати методи-
ку, описану для розподілених систем. Важлива відмінність заклю-
чає в тому, що для заклинання об'єктів БД сервер БД і його про-
раз повинні підтримувати повідомлення "заклинання". У конкретно виготов-
лення реалізації для цього застосовувався такий засіб об'єктивним
тно-орієнтованих БД як динамічний заклинання. Дії сер-
віра БД при отриманні заклинання:
- Оттрансліровать аргументи на робочий формат;
- Скласти з аргументів список і викликати механізм динамічних
чеського заклинання для його обробки;
- Повернути результат як список із значень базових типів і
ідентифікаторів об'єктів.

Dispatching бази правил.

Традиційно системи працюють з базами правил мають закриту ар-
хітектуру і включають в себе інтерфейс бази даних, що зберігає ці
правила. У результаті правила справляють істотний вплив на
системні питання, такі як база даних і мова програмування.
У цій серії експериментів автори намагалися зрозуміти метод забезпе-
ня гнучким dispatching зв'язку між правило-й об'єктно-орієнтир-
ванними парадигмами.

Модель бази правил.

Традиційно системи складаються з двох частин: правил і фактів.
Серцем системи є процесор правил, що використовує правила і
факти для досягнення мети. Єдиним шляхом внесення в систему
даних є декларація фактів. Правда, системи працюють з
великими обсягами даних, часто об'єднані з БД і користувач
може як декларувати факти, так і безпосередньо працювати з таблиця-
ми БД.

Для приведення баз правил до виду об'єктів ми повинні реалі-
вати загальний механізм, що дозволяє їм доступ до зовнішніх даних - се-
тевие заклинання; зокрема, це дасть БП доступ до віддалених БД.
Тепер БП сама може розглядатися як розподілений об'єкт.

Правила як методи об'єкту.

Для використання правил в роботі об'єкту слід просто
реалізувати диспетчер, делегує роботу процесору правил в
Відповідно до заклинанням. Разом з доступом до БД ми отримуємо,
що база правил є об'єкт зі станом - даними БД і методами -
правилами, також зберігаються в БД. Зазвичай небажано, щоб
правила безпосередньо зверталися до БД; відповідно, диспетчер дол-
дружин передавати базі правил свій власний ідентифікатор і про-
цессора правил буде звертатися до нього з заклинаннями доступу до
даними.

Винесені ув'язнення і невирішені проблеми.

У ході експериментів з'ясувалося наступне:
- Хоча в початковій ідеї заклинання розбивалося на адреси і
аргументи, часто зручно розглядати заклинання як нерозривний
сутність;
- "Хороші" повідомлення по ідеї повинні розумітися всіма під-
держіваемимі об'єктами. Hепонятно, як бути у випадку, коли пові-
щення безглуздо для приймаючого - відповісти деяким стандар-
тно-безглуздим чином або віддати об'єкту і дозволити йому про-
працювати і/або згенерувати виключення;
- Виникають питання з конкурентним доступом до об'єктів в
розподілених системах. В даний час йде розробка додат-
нений, які дозволять реалізувати будь-який з методів управління
конкуренцією, запропонований у прикладних системах;
- Метаоб'екти. У системі слід організувати якийсь мета-у-
рівний і дозволити доступ до нього диспетчерів. Явна вказівку ал-
горітмов диспетчеризації подібно до використання goto: і гнучко, і
небезпечно. Поступово виділяться спільні шляхи диспетчеризації, які
стануть високорівневим абстракціями;
- Відділення мета-і базового рівня. Суміш в одному Менеджер-
ре доступу до обох рівнів важка для сприйняття;
- Оптимізація. Перевагою запропонованої схеми є те,
що вона не розрахована на конкретний метод диспетчеризації і, сле-
послідовно, можливо оптимізувати будь-які частини працює
системи не порушуючи роботи інших.