Ответ на »сообщение 2873« (Сергей Губанов)
___________________________
>>>Шутка основана на подмене понятия "модуль".
Отнюдь.
>>>В оберонах модуль - единица исполнения.
Заметим И исполнения. Я уже высказывался на эту тему - совмещение единицы текста, единицы трансляции и единицы исполнения уменьшает число сущностей, но приводит к тому, что приходится писать большие, плохообозримые тексты.
Мне действительно не хватает unit в Обероне. Мы вернулись к классическому Паскалю, в котором программа должна вся помещаться в одном файле. Это хорошо для учебных примеров. Далеко не каждую программу можно представить в виде набора НЕБОЛЬШИХ независимо загружаемых модулей.

Стал нередко использовать агрегацию-композицию (кстати, может кто дать ссылку на более-менее точное определение этих понятий?) вместо наследование, о чем не жалею, хотя сперва тоже были вопросы по поводу дискриминации наследования в Обероне.
Насколько я понял, межмодульное наследование в Обероне, мягко говоря, не приветствуется, поэтому отказаться от конструкторов было логично. Больше смысла неиспользовать в этом качестве фабрики, нет.

Ответ на »сообщение 2873« (Сергей Губанов)
___________________________

Единицей исполнения в делфи является exe-шник.

Либо .bpl (.dll).

Вся дельфийская VCL, с точки зрения "оберон-модульности", действительно размещается в одном единственном модуле. Межмодульный импорт/экспорт в дельфи вообще отсутствует: один exe-шник не может импортировать другие exe-шники.

А как же packages? VCL-то на них в основном построена.

Ответ на »сообщение 2871« (AVC)

...возникают проблемы с наследованием. По сходной причине немного сомневаюсь в активных объектах...

Это распространённое заблуждение. Например, Б. Мейер когда выступал со своей лекцией в ННГУ про активные объекты то же самое сказал. На самом деле, никакой проблемы нет по той простой причине что единицей расширения (наследования) являются DEFINITION-ы, а не типы активных объектов. Типы активных объектов не расширяемы.

Ответ на »сообщение 2867« (Сергей Перовский)

Представляю себе VCL в одном модуле :)

Шутка основана на подмене понятия "модуль". Очевидно, что Вы в данном случае подменили понятие оберон-модуля на дельфийский unit. В оберонах модуль - единица исполнения. Единицей исполнения в делфи является exe-шник. Вся дельфийская VCL, с точки зрения "оберон-модульности", действительно размещается в одном единственном модуле. Межмодульный импорт/экспорт в дельфи вообще отсутствует: один exe-шник не может импортировать другие exe-шники.

Один из альтернативных способов борьбы с неустойчивостью прикладной области и изменением требований:
http://www.embedded.com/story/OEG20010725S0103

Ответ на »сообщение 2868« (Сергей Перовский)
___________________________

>>>Удачно построенным иерархиям наследования могут предшествовать годы теоретических исследований.

Сергей, насколько я могу судить, Вы хороший аналитик.
То, что Вы пишете о построении дискретных систем, в целом согласуется с моим (правда, значительно менее богатым) опытом в этой области.
(В частности, согласен, что функциональный подход в подобных системах играет подчиненную роль. ИМХО, могу достаточно точно указать его место "пальцем". :) Есть и небольшие расхождения. Например, вместе с Русланом Богатыревым сомневаюсь, что КА оптимально представлять в виде класса. На мой взгляд, здесь возникают проблемы с наследованием. По сходной причине немного сомневаюсь в активных объектах Active Oberon.)
Возможно, предметные области, с которыми Вы связаны, уже "устоялись".
Или Вы владеете неким секретом, как ASU.
Но частенько случается так, что именно прикладная часть системы неустойчива. Подумайте о причинах распространения т.н. "гибких" методологий (в частности, XP).
Если же не ограничиваться прикладной областью ("прикладным доменом" у Шлаер и Меллора), то возможные выгоды от некоторого ограничения наследования становятся (еще) более очевидны. Представьте себе, что Вы можете "на лету" заменить базовый класс и поведение/вид целого семейства объектов, отказавшись от наследования в пользу делегирования и композиции. Достаточно пере-коммутировать объекты (пользуясь термином Р.Богатырева).

На тему языков-сундучков и программистов-непрофессионалов.

В книжном магазине набрел на любопытную книгу Дональда Нормана "Дизайн привычных вещей".
Купил, когда наткнулся на фразу:
В целом, я приветствую любое новшество, которое уменьшает умственную нагрузку и при этом дает мне возможность управлять и наслаждаться своей работой. Так я могу сосредоточиться на сути задачи. Я хочу с толком использовать свои умственные способности, а не распылять их на мелочи.

Ответ на »сообщение 2867« (Сергей Перовский)
___________________________

>>>Представляю себе VCL в одном модуле :)

Да уж... :)
Конечно, я имел в виду иерархии прикладных классов.

Ответ на »сообщение 2861« (AVC)
___________________________

2 Сергей Перовский

Почему-то подумалось, что хрупкость базовых классов можно проиллюстрировать знаменитым рассказом Бредбери "И грянул гром" (там охотник, попав в прошлое, случайно наступает на бабочку).
У нас с Русланом Богатыревым разное отношение к идеологии решения задач и потому разное отношение к иерархиям наследования.
Удачно построенным иерархиям наследования могут предшествовать годы теоретических исследований. Если же "главное ввязаться в бой", то ООП действительно опасный и малопредсказуемый инструмент.
Если я (смею надеяться) построил несколько удачных ООП систем, то потому, что глубоко "в теме". По некоторым направлениям по 20-30 лет. Теперь эти иерархии можно развивать, но сломать их проблематично - для этого нужно опровергнуть математическую модель определенного класса систем.

Ответ на »сообщение 2865« (AVC)
___________________________

2 Сергей Перовский

Если у Вас наследование всегда сводится к единичному (почему-то хочется назвать это "каррингом наследования" :) ), то почему бы просто не поместить каждую иерархию в отдельный модуль?
В его рамках на Обероне-2 и КП вполне можно писать в духе традиционного ООП, а связь между родственными классами, думается, достаточно сильна, чтобы оправдать их размещение в одном модуле.
Представляю себе VCL в одном модуле :)