Оберон-клуб «ВЄДАsoft»

Опции нужно выделять в отдельный интерфейс. Если есть две составляющие - обязательная и опциональная, то напрашивается, что это отдельные сущности. Композицию можно применять не только вместо множественного наследования.

Слишком категоричное утверждение "нужно" про опции. Однако согласен, особенно в русле вашего проекта Восток, что такая точка зрения имеет право на существование. Для многих программ не нужно городить такой ООП. Это всё применимо главным образом для разработки каркасов. Не стоит забывать, что и сам Компонетный Паскаль был создан во время и для задачи создания фреймворка.

Множественное наследование хотя бы интерфейсов заменить композицией нельзя.

Надо уточнить, что нельзя заменить так, чтобы те, кто привыкли ипользовать эту возможность часто и в полной мере, сочли это удобным. Но речь-то не о буквальной замене, иначе и смысла бы не было.
Множественное наследование имеет ещё и тот недостаток, что многие вольно или невольно раскрывают дополнительные возможности для владельца одной из граней, который может сделать приведение и начать вызывать не то, что нужно, что является разновидностью нарушения сокрытия.

Предложи пожалуйста пусть не буквальную замену, но чтобы было удобно. На примере какого-нибудь "IComparable".



И чтобы без этого недостатка.

Нужна более конкретная задача, пока мне неясен смысл примера.

Совсем частную задачу можно вообще без ООП решить. Скорее всего еще и эффективнее. ООП дает профит на сложных эволиционирующих системах. В том числе там, где надо "ужа с ежом", отчего оберонщики обычно сразу крутят носом - дескать наговнокодили тут, в оберонподходе такого не бывает, следующий.

Ну ладно, вот более частный, но все равно достаточно общий пример. Зачастую возникает ситауция, когда один и тот же объект должен обладать набором свойств A, B, C, чтобы с ним могли работать компоненты ComponentA, ComponentB, ComponentC. При том, что свойства примерное из одной оперы, например IComparable vs IEquatable, линейным наследованием они выражаются плохо, т.е. A->B->C или A->C->B неочевидно. Поэтому на этапе разработки компонентов мы не хотим строить (хрупких) иерархий, а просто зафиксировать минимальный интерфейс необходимй для работы компонента. В процессе эволиции системы, если у нас все три кмпонента должны уметь обрабатывать один и тот же объект - задача тривиально решается в помощью множественного наследования.

Композиция заставит писать адаптеры + специализированный интерфейс ABC (если надо такой объект использовать в разных местах). Message bus - слишком гибко, неконтроллируемо и многословно. Предложи свой вариант.

Я обычно отделяю операции от объектов, потому что те же сравнения или сериализация могут быть разными для одного и того же типа в зависимости от контекста. Если бы мне нужны были три интерфейса для трёх компонентов, то я бы использовал композицию интерфейсов, и нужному компоненту передавался бы только объект и нужный интерфейс.
Уверен, что в Design Patterns такое должно быть описано.

Пример Влада, если я правильно понял, несложно решается методом композиции через включение любого из трех объектов в виде ANYREC, как сделано у Петра в его расширении Lists. Какие бы вы объекты на начальном этапе не спроектировали, вы всегда потом сможете, например, сложить в список и обрабатывать в последующем в зависимости от типа через WITH.

Про EMPTY сегодня наткнулся в заметке Куно Пфистера


http://oberon2005.oberoncore.ru/paper/cp_java.pdf