Владислав Жаринов писал(а):
Ага... значит, схемы со сращением деревьев по листам или корням, как
здесь?.. или можно сращивать также листы одних с узлами/корнями других?..
Можно всё, что угодно. По схеме: "имеющиеся классы" + "независимые переменные" + "независимые процедуры" -> "обработка в базе данных" -> "копипэйст новых классов в программу" + "автоматизированный (с помощью базы данных) мониторинг изменений в базовых классах по желанию программиста"
Владислав Жаринов писал(а):
Отсюда и вопросы:
Сергей Прохоренко писал(а):
...
Структурный редактор должен контролировать внутреннюю непротиворечивость полученной конструкции (возможность применения методов к объектам). Никакие последующие изменения в исходных классах уже не повлияют на новый класс.
...
- какова математика такого контроля?
Проверки во время конструирования программы или компиляции: (1) объявлены ли в новом классе все необходимые поля, обрабатываемые при вызове всех его методов (выдача ошибки "нет поля или лишний метод"); (2) есть ли в новом классе поля, не обрабатываемые ни одним из его методов, кроме конструктора (выдача ошибки "нет метода или лишнее поле")?
Владислав Жаринов писал(а):
Сергей Прохоренко писал(а):
...
Можно (поскольку мы имеем дело с удобной реляционной базой данных!!!) автоматически отслеживать все изменения в исходных классах (программисту достаточно сконструировать запрос) и предлагать программисту внести соответствующие изменения в новый класс.
...
- так всё-таки полуавтоматически (т.к. с участием человека)? а как автоматически (когда среда сама поо изменениям структуры классов перестраивает запросы и инициирует их)?
Полный автоматизм означал бы, что изменения в базовых классах автоматически приводят к изменениям в классах-потомках, что выводит процесс из-под контроля человека. Раз построенные запросы не нуждаются в перестройке, инициировать их можно автоматически. Но за программистом должно оставаться санкционирование (акцепт) предлагаемых запросом изменений.
Владислав Жаринов писал(а):
И в целом - какие преимущества это даёт сочинителю и другим участникам? На фоне очевидного усложения среды для разработки и в исполнении (в сравнении с одиночным наследованием)?.. И есть ли математическое обоснование, что так можно сделать что-то, что принципиально нельзя с помощью одиночного? или напротив, это эквивалентные формы структурирования (как по Бёму-Джакопини для маршрутных схем)?..
Я, наоборот, вижу здесь упрощение среды для разработки. Вместо дерева классов, всяких там UML-диаграмм, ООП-синтаксиса в языке и ООП-наворотов в компиляторе - в среде разработки остается только средство для связи данных с простой настольной базой данных, а в базе данных - запросы для проверки внутренней непротиворечивости новых классов.
Преимущества следующие:
- нет лишних и оторванных от предметной области чересчур абстрактных интерфейсов и классов;
- нет проблемы "хрупкости базового класса (или неожиданных изменений интерфейса)";
- фактически возможно множественное наследование - но под полным контролем программиста;
- есть возможность автоматизированного мониторинга изменений в базовых классах (интерфейсах);
- все изменения типов происходят в явном виде во время компиляции или до нее - под полным контролем программиста и среды разработки;
- не наследуется лишнее;
- поиск полей и методов, необходимых для создания нового класса, автоматизирован.
Всё вышесказанное может сочетаться и с классическим одиночным наследованием, если в этом имеется реальная необходимость. Но пока я такой необходимости не вижу.