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

Модуль должен быть достаточно компактным и ясным, чтобы его быстро понял среднестатистический студент. Достаточно?

Давайте все же будем отделять мух от котлет. Об обучении вопрос всплыл только сейчас. Все-таки речь шла о проектных решениях для практических проектов, а не об удобстве для учебных занятий. И критерии мы обсуждаем применительно к этому (реальным практическим проектам). Опять-таки если преподаются студентам задачи программной инженерии на примере реальных проектов, то не очень понятно, зачем надо эти проекты масштабировать вниз для "удобства студентов". Если студенты изучают курс по операционным системам и смотрят исходники классического UNIX System V (например) или той же Oberon V4, то никаких предпосылок переделывать проектные решения в угоду пониманию студентов лично я не вижу.

У меня работает объект-КА, причем он является наследником абстрактного динамического объекта, который, в свою очередь унаследован от TComponent. Но это все детали реализации. От КА у меня создан всего один наследник - Технологический КА, в основном наследование не требуется, необходимо только заполнить таблицу и можно описать любой КА не создавая новых типов.
Хотелось бы узнать подробнее, в чем Вы видите проблему - мне это действительно важно.

Проблемы нет. Я задал вопрос, чем был обусловлен выбор ООП для представления КА по отношению к другим подходам (в частности, модульному программированию). Вопрос, увы, повис в воздухе. Либо такой выбор не делался, и задача решалась исходя из удобства (владения инструментом, знания ООП, обстоятельств и т.п.), либо альтернативы все же рассматривались. Но даже если и не рассматривались, то что мешает это сделать сейчас (или признаться в том, что модульное программирование было за рамками альтернатив)?

Ответ на »сообщение 2883« (Сергей Перовский)
___________________________
А я бы ввел один абстрактный интерфейс "подвижный объект", в котором предусмотрел обработку типизированных сообщений различного рода через Generic Message Handler.
А затем заводил бы конкретные реализации подвижного объекта. Как только выделяется какое-то общее для различных ПоОб поведение, я бы выносил его в отдельные классы, отвечающие исключительно за обработку тех или иных ситуаций, инкапсулирующие некоторый аспект "интеллекта". Эти классы можно было бы комбинировать между собой в различных сочетаниях, без наследования быстро реализовывая требуемые конкретные подвижные объекты. Например, LatentBehavior, AgressiveBehavior, ShootBehavior и т.п.

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

Раз уж тут обсуждаются принципы ОО-проектирования, не могу удержаться от ссылки:

"How to Produce the Best OO Programmers" by Shriram Krishnamurthi :
PowerPoint , PDF или PDF with animations

Ответ на »сообщение 2881« (Руслан Богатырев)
___________________________
>>>"Хочу" должно быть чем-то обусловлено весомым, кроме собственно желания.
Хорошо, поясню почему "хочу".
Модуль должен быть достаточно компактным и ясным, чтобы его быстро понял среднестатистический студент. Достаточно?
Мы же говорим и о возможности использования языка в обучении. 800 строк многовато.
Но главное конечно не в этом. Я стараюсь использовать максимально глубокое наследование, да простит меня Мессенбек. Это нужно, чтобы наследники не тащили в себе ничего лишнего. Функциональность наращивается очень осторожно, чтобы не получилось наследования кенгуру от солдата. И если мне нужно включить в проект базовый класс и 4 его наследника, то у меня должна быть такая возможность. Не 25, а только те 4, которые нужны в данном проекте.
Если бы тот австралийский вертолетный тренажер писал я, то не стал бы сразу писать объект-солдат противника. Даже не являясь экспертом в вертолетных симуляторах я стал бы писать очень глубокую иерархию: подвижный объект, подвижный объект с реакцией на наблюдателя, подвижный объект с реакцией на наблюдателя на поверхности земли и т.д. солдат возник бы на 5-6 уровне. Зато потом, когда потребуется моделировать свою и чужую авиацию, гражданских лиц и автомобили и т.д. я буду наследовать их без избыточных данных и реакций.
Кроме того я получу наработки для аналогичных проектов. То, что я публиковал в сокровищнице - модули которые были использованы больше, чем в одном проекте.
А как Вы поступаете, если в другом проекте требуется пара объектов из модуля в 1000 строк?

Ответ на »сообщение 2881« (Руслан Богатырев)
___________________________
"Хочу" должно быть чем-то обусловлено весомым, кроме собственно желания.
Ну оно может например быть обусловлено желанием продавать свою библиотеку классов без исходников, но чтобы у ваших покупателей сохранялась возможность расширения класов, купленных ими за свои кровные между прочим.
Или скажем оно может быть обсуловлено тем что в проекте вы сажаете за базовые классы опытного специалиста (который у вас один), а за расширения - команду джуниоров, которых на базаре 5 копеек за пучок.

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

Только что был совет помещать каждую иерархию классов в один модуль.
Какого размера модуль?
У меня получится 500 - 1000 строк.
Не хочу такие длинные исходные файлы.
Хочу по 1 - 3 класса в текстовом модуле, чтобы в 50 - 150 строк.

"Хочу" должно быть чем-то обусловлено весомым, кроме собственно желания. Вообще говоря, задача поиска компромисса (сколько классов поместить в один Оберон-модуль) требует вдумчивого подхода. Резать на глазок (завесим так граммов 150) -- не инженерный подход. :)

По своему опыту работы в Modula-2 (он на порядок выше, чем в Обероне) "нормальный" объем модуля -- порядка 800-1200 строк. Больший объем приводит к проблемам с пониманием (Вирт устанавливал свой рубеж понимания -- что-то около 5 тыс. строк на весь модульный проект -- это если для одного человека, который должен быть уверен в любом закоулочке). В случае Оберона класть всегда один-два класса в модуль в общем случае неразумно.

Итак, нужны критерии "распилки" классов по модулям. Знаем, что расширение (наследование) через границы модулей в Обероне уязвимо, но далеко не смертельно. Более того, нормально работает, хотя возникают подводные камни (считайте, что межмодульное расширение типа -- чувствительный к помехам канал связи).  Эти проблемы в большей степени нивелируются в КП, нежели в классическом Обероне. Считайте Оберон-модули чем-то вроде "сборок" классов. Внутри модуля с классами работать одно удовольствие. Объединять их можно исходя из критической массы "служебных" межклассовых входов и "жесткого" наследования. Для "мягкого" наследования используется расширение через границы модулей. Там "проводов" будет сильно меньше.

Оберон-модуль может быть как независимой программой (прямое отображение в EXE), так и составной частью системы или библиотеки (компонентом или "сборкой", часть DLL). Один модуль может потащить за собой целый куст других (что обусловлено связью экспорта-импорта). Отсылки к Паскалю говорят о том, что с Оберон-модулем пока еще непонятки. А раз это -- ключевая вещь в языке, то рассуждения о плюсах и минусах Оберонов без четкого понимания этой сущности теряют очень много.

В случае Оберонов система декомпозируется на подсистемы. Единицей строительства подсистем являются модули. В модулях размещаются классы (в той части, где используется именно ООП). В подсистеме можно выделить "инвариантную" часть (application-independent) и специфическую для проекта часть (application-specific). Инвариантная часть формирует каркас (framework). Это то самое обобщение, которое подразумевает конкретизацию под специфику задачи. Оно строится из абстрактных и конкретных классов, размещенных внутри модулей.

В книге Мессенбека "Object-Oriented Programming in Oberon-2" затрагивается проблема слишком глубокой иерархии наследования. Это не проблема Оберонов. Это общая проблема ООП. По замечанию Мессенбека, в Smalltalk очень часто встречаются излишне глубокие иерархии, это связано с тем, что активно применяются конкретные классы, исходный текст каждого класса доступен и расширение ведется преимущественно с целью повторного использования кода. Его вывод: надо грамотно балансировать абстрактные и конкретные классы (балансировка дерева) и стремиться по возможности не допускать неконтролируемого роста глубины иерархий наследования.

Ответ на »сообщение 2879« (Geniepro)
___________________________
>>>Что-то непонятно... Ведь модули Оберона дают всё, что могут дать юниты Паскаля, как же Вам может их не хватать?
Только что был совет помещать каждую иерархию классов в один модуль.
Какого размера модуль?
У меня получится 500 - 1000 строк.
Не хочу такие длинные исходные файлы.
Хочу по 1 - 3 класса в текстовом модуле, чтобы в 50 - 150 строк.
Тогда требуется наследование через границы модулей.

Еще раз, медленно:
1.Размеры единиц редактирования и единиц загрузки определяются совершенно разными соображениями. В Обероне размеры равны т.к. это одни и те же единицы.
2.Наследников от базовых классов могут писать разные люди. При отсутствии наследования через границы модулей они вынуждены редактировать один файл. Мне такая идеология не нравится очень. У каждого файла должен быть автор. О системах для совместной работы я знаю, но по моему это попытка автоматизировать беспорядок.


Объединение этих единиц в единое понятие модуля порождает проблемы.

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

Мне действительно не хватает unit в Обероне. Мы вернулись к классическому Паскалю, в котором программа должна вся помещаться в одном файле.

Что-то непонятно... Ведь модули Оберона дают всё, что могут дать юниты Паскаля, как же Вам может их не хватать? Что есть такого в юнитах, чего нет в модулях?
Модули вовсе не обязаны быть независимыми от других...

Ответ на »сообщение 2871« (AVC)
___________________________
>>>Сергей, насколько я могу судить, Вы хороший аналитик.
Спасибо на добром слове :)
>>>Например, вместе с Русланом Богатыревым сомневаюсь, что КА оптимально представлять в виде класса. На мой взгляд, здесь возникают проблемы с наследованием.
У меня работает объект-КА, причем он является наследником абстрактного динамического объекта, который, в свою очередь унаследован от TComponent. Но это все детали реализации. От КА у меня создан всего один наследник - Технологический КА, в основном наследование не требуется, необходимо только заполнить таблицу и можно описать любой КА не создавая новых типов.
Хотелось бы узнать подробнее, в чем Вы видите проблему - мне это действительно важно.

>>>Возможно, предметные области, с которыми Вы связаны, уже "устоялись".
В том смысле, что нам удалось построить эффективные математические модели.

>>>Или Вы владеете неким секретом, как ASU.
Этот секрет называется системным анализом :)

>>>Но частенько случается так, что именно прикладная часть системы неустойчива. >>>Подумайте о причинах распространения т.н. "гибких" методологий (в частности, XP).
Причины понятны. Как уже описал Руслан: контракт уже заключен, а что делать не понимают ни заказчик ни разработчик. Тогда первые варианты реализации нужны только для того, чтобы заказчик более внятно сформулировал, что ему на самом деле нужно. Это работает. Мы пользовались таким методом при настройке системы составления расписаний - изначально заказчик формулирует далеко не все ограничения, только когда ему показывают составленное расписание он говорит: нет, вот так быть не должно.
В большинстве случаев я использую другой метод - нужно встать на место заказчика, т.е. научится делать его работу. Тогда я сам могу поставить задачу полностью. И гораздо лучше его, т.к. понимаю, чем может помочь компьютер.
Это долго, это сложно, но это работает.

>>> Представьте себе, что Вы можете "на лету" заменить базовый класс и поведение/вид целого семейства объектов, отказавшись от наследования в пользу делегирования и композиции. Достаточно пере-коммутировать объекты (пользуясь термином Р.Богатырева).
Вот тут я ничего сказать немогу. Мне не представить.
Как могут две различные иерархии отличаться только базовым классом, я не понимаю.
Я знаю, что для таких случаев в последних версиях Дельфи введены механизмы рефакторинга, но пока они мне не понадобились ни разу. Можно какой нибудь пример?

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

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

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

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

Вы думаете, что иерархии прикладных классов принципиально меньше VCL?
Во многих случаях это так, но мы говорим о действительно СЛОЖНЫХ задачах.