Исходя из конструктивной идеи этой ветки:
... нет уголка с табличкой, куда ткнуть любого желающего. (Или я уже забыл?)
...
- возникают некоторые вопросы. Как-то:
1. Эта формулировка:
В
обсуждении WITH созрело некое, вроде бы, подтверждение (моего любимого) тезиса, что интерпретация ООП в Оберонах выявляет фундаментальный смысл ООП как способа расслоения функциональности между модулями в настоящей модульной системе.
Когда управление списком -- в одном модуле, а наполнение элементов списка конкретным смыслом -- в других.
...
- означает ли, что ООП используется в ситуациях, как задача "Гетерогенная очередь" у Свердлова? И что должно использоваться всегда именно так? Или можно сформулировать "строчки для таблички" вида: "если анализ даёт такую-то структуру сущностей задачи - используй расслоение такое-то (как у Свердлова)"; "если этакую - используй расслоение эдакое (скажем, с каким-то множественным наследованием - или его эмуляцией через одиночное)". Причём способы эмуляции д.б. рассмотрены где-то рядом с табличкой...
И также - как она соотносится с этим:
...
Например, возможен такой вариант. В каждом модуле должна быть создана
сводная для всех классов интерактивная таблица виртуальных методов, в которой программист непосредственно и в явном виде указывает связи между классами и методами. При внесении изменений в эту таблицу происходит автоматический рефакторинг всего кода модуля, при котором имена абстрактных методов заменяются на имена реализаций методов. Необходимость в позднем связывании отпадает.
- противоречит? альтернативно?
2. Альтернативная организация, как сформулирована здесь:
Владислав Жаринов писал(а):
Валерий Лаптев писал(а):
Композиция - ЕСТЕСТВЕЕННЫЙ метод реализации многофункциональности в одном классе.
...
Одиночное наследование + композиция - это хороший вариант.
Т.е. композиция здесь понимается не в смысле структурности - конкатенации структур с одним входом и одним выходом (ну или как в математике - цепочки функций)?.. Или как?
Композиция - это прямо в лоб: объект уже реализованного класса включается как поле в новом классе. Тем самым новый класс получает всю функциональность реализованного класса. Только не по наследству, а через объект реализованного класса.
- как делается практически? каковы закономерности отображения структуры сущностей задачи в эту схему? В общем опять же - как будут выглядеть "строчки в табличке"?..
3. Инициирующий пост ветки вроде бы располагает поставить и такой вопрос - не дать ли также закономерности отображения ООП-1 на ООП-0 ("фантазийных схем" в базис реализации). Но тут возможен ещё путь, коего уже коснулся:
viewtopic.php?p=72010#p72010.
Теперь уточню. Не нужно ли на математической стадии формализации задачи уже заботиться об ограничении фантазий? Т.е. чтобы уже спецификация, как правило, соответствовала ООП-0?
О такой возможности задумывался в связи с "графитизацией" Оберонов "как положеноо" (в "базисе трёх абстракций" Кауфмана - ну или четырёх по Вирту-Бадду). Т.е. с выделением структур всех компонент базиса - а не только потока управления с "притыканием" остальных к нему. И окончательно это оформилось после знакомства в "АиСД-Оберон" с мыслями Вирта о соответствии сущностей структур данных и управления.
А отсюда такая мысль появилась. В теории структур данных, как известно, определены закономерности нормализации. Не значит ли такое соответствие, что пора искать аналогичные закономерности и для структур управления?.. И не это ли д.б. приоритетным предметом здесь:
Валерий Лаптев писал(а):
Налицо необходимость конкретного исследования.
Хорошо бы фундаментального, лет на 20-30. И чтобы исследователь попался не просто теоретик, но и практик...
viewtopic.php?p=71865#p71865...
Возмоожно, природа сама подскажет нам, как получать естественное для конкретного аналитического выражения задачи отображение на уровень реализации (с непременным учётом "абстракции исполнения" - в форме хоть "связывания" у Кауфмана, хоть "систематического представления об архитектуре" у Вирта) - вместо того, чтобы пытаться обманывать природу исполнителя?..