на примере простого графического движка "с механикой".
моя реализация требовала объект, который бы поддерживал два разнородных контракта - рисование и движение.
в яве я делал так
в той части, что отвечает за отрисовку сцены описывал
Код:
interface Drawable {
public abstract void draw();
}
в той части, что отвечает за механику объектов
Код:
interface Movable {
public abstract void moveTo(int dx, int dy)
}
затем, в части, которая предоставляла собой "движок"
Код:
public class Frame implements Drawable, Movable {
// здесь реализуем draw и moveTo
}
прикладная же часть состояла из реализаций
Код:
public abstract class View{
public abstract void paint (Frame f);
}
Но теперь я понял, что всё это фигня. Так как у меня в ББ не было возможности реализовать такое решение, я выбрал другое
Код:
Object* = POINTER TO ABSTRACT RECORD END
PROCEDURE (o: Object) HandleMsg(m: Msg), NEW, ABSTRACT;
Если бы Meta в ББ могла вызывать методы - было бы совсем просто. Но, так как она не умеет методы, пришлось сделать так:
Реализация Manager будет заниматься рассылкой объектов-сообщений зарегистрированным в своём внутреннем списке, объектам.
Код:
Msg* = POINTER TO ABSTRACT RECORD;
Manager* = POINTER TO ABSTRACT RECORD END;
Link* = POINTER TO ABSTRACT RECORD;
PROCEDURE (m: Manager) Register(link: Link), NEW, ABSTRACT;
PROCEDURE (l: Link) Handle(m: Msg), NEW, ABSTRACT;
и в реализации прикладной логики делаю так:
Код:
MyFrame* = POINTER TO RECORD(Object) END;
PROCEDURE (o: MyFrame) HandleMsg(m: Msg);
BEGIN
WITH m: MyEngine.MoveToMsg DO
|m: MyEngine.DrawMsg DO
ELSE END;
END HandleMsg;
MyLink* = POINTER TO RECORD (Link) (* решаем задачу неполноты Meta *)
o: MyFrame
END;
PROCEDURE (m: MyLink) Handle (m: Msg);
BEGIN
m.o.HandleMsg(m);
END Handle
Если уж совсем конкретно, то при использовании шины AbfBus и широковещания не нужен даже тип Link, его роль играет модуль.
но тогда придётся всюду таскать за собой идентификатор объекта, подлежащего обработке. Конкретно этим подходом пользуюсь в своей повседневной деятельности. Недавно предпринял попытку расширить схему до вышеизложенной (где хэндлер уже у объекта), вроде пока работает.
Вообщем-то, физический смысл "тело, которое видно и которое двигается" одинаково передают оба подхода.
Задача решена, множественные интерфейсы не нужны.