Ответ на »сообщение 2891« (Руслан Богатырев)
___________________________
>>>Выбор Вами решения был обусловлен, на мой взгляд, Вашей жесткой привязкой к ООП ("зашоренностью"), а не сображениями инженерной целесообразности.
Мы опять приходим к одной и той же причине разногласий. Я не интересуюсь инженерной целесообразностью. Я делаю инструмент для построения сложных имитационных моделей. И тот, кто будет пользоваться этим инструментом должен думать не как программист, а как аналитик - в терминах задачи. Ему нужны объекты, соответствующие элементам модели: пассажир, корабль, станок. Можно предложить ему набор ЛЕГО, но так труднее думать о задаче в целом. Иногда так приходится делать "из сображений инженерной целесообразности". Но это не может быть "магистральной технологией".
Напомню, что ООП изначально создавалось именно для целей имитационного моделирования, чтобы дать возможность думать в объектах задачи.

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

>>>Добавляю свое свидетельство: на совершенно другом прикладном материале у меня произошла точно такая же эволюция: от мучений с наивным выстраиванием иерархий "объектов" к организации посредством этой самой "software bus" (термин AVC).

Термин все же не мой.
Я его встретил в "Oberon White Paper" (причем в сочетании со словом Technology), и он показался мне гораздо более ясным (само-объясняющим), чем аналоги, поэтому я стал использовать именно его.

Аналогии с hardware bus можно встретить в разных работах по Оберону (и не только).
Например, в статье Гуткнехта "Oberon, Gadgets and some Archetypal Aspects of Persistent Objects" (1996):
This architecture can be looked at as a software analogy to the familiar hardware bus: If they comply  with the given bus protocol participating components of any kind simply plug in.

Пример из "необероновских" источников:
Ivy is the software bus that will creep over your network!


P.S. Прошу прощения за задержку с ответами.

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

Речь идет о целесообразности использования ОО-проектирования и ООП для решения любых задач. Априори может быть очевидно, что сколь бы хорош ни был подход/инструмент, у него всегда есть изъяны. И они связаны нередко с его достоинствами. Изъяны надо знать и понимать, иначе подход/инструмент используется как минимум неэффективно (если даже вообще по назначению, вспомним про микроскоп и гвозди).

Обратите внимание, что нередко обсуждение крутится вокруг вопросов о том, чем лучше реализация ООП в Обероне/КП, нежели в других языках из мэйнстрима. Здесь есть свои плюсы и минусы (КП делался после Java и ставил целью нейтрализацию проблем Java). Но почему-то абсолютно замалчивается вопрос о том, что Оберон/КП позволяют походить к проектированию и реализации систем иначе, нежели только через ООП. Думаю, стоит к этому вопросу вернуться. Тем более, что недавно еще раз прочел интересный фрагмент, который весьма актуален для нынешнего обучения ООП.

Творческой составляющей в программировании -- которое следует отличать от кодирования (coding) -- обычно учат на основе примеров, которые служат для демонстрации определенных методов программирования. В данной статье она рассматривается как последовательность проектных решений, связанных с декомпозицией задачи на подзадачи и данных на структуры данных… Опыт показывает, что успех учебных курсов по программированию в значительной степени зависит от выбора этих примеров. К сожалению, они частенько отбираются с основным желанием продемонстрировать, как компьютер может работать. На самом деле, главным критерием для выбора должно быть то, насколько они подходят для демонстрации определенных широко используемых методов. Более того, примеры программ в основном представляются как законченные "продукты", после чего следует объяснение их назначения и их деталей языковой реализации. Но активное программирование в большей степени состоит в проектировании новых программ, нежели в созерцании старых. Как следствие такого подхода к обучению, студент получает впечатление будто программирование заключается в основном в мастерстве владения языком (со всеми странностями и "наворотами", столь изобилующими в современных языках программирования) и опирается на интуицию конкретного человека по тому, как трансформировать идеи в конечные продукты. Ясно, что учебные курсы по программированию должны обучать методам проектирования и конструирования, а избранные примеры должны быть такими, чтобы хорошо продемонстрировать постепенную разработку.

Как вы думаете, когда и кем это было написано? Никлаус Вирт, апрель 1971 г., статья "Program Development by Stepwise Refinement".

Ответ на »сообщение 2886« (Руслан Богатырев)
___________________________
>>>Все-таки речь шла о проектных решениях для практических проектов, а не об удобстве для учебных занятий.
Виноват, после фразы прос студента нужно было поставить смайлик :)
Естественно, суть в том, чтобы включать в проект только необходимую часть иерархии.

Ответ на »сообщение 2889« (info21)
___________________________
>>>Сильное впечатление, что С.П. не прочувствовал прелесть и мощь схемы "software bus".
А так же модульного и функционального программирования, SQL, ADO, .NET и многого другого :)
Что не мешает мне всем этим пользоваться.
Сколько можно сравнивать микроскоп с радаром...
Причем в большинстве случаев на опыте забивания гвоздей :)

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

В задаче их може быть много. Я уже писал, что работаю с ансамблями автоматов.

Модульность не отвергает множественность. Если ансамбли автоматов не используют специфических особенностей ООП (а какие они используют?), то выбор Вами решения был обусловлен, на мой взгляд, Вашей жесткой привязкой к ООП ("зашоренностью"), а не сображениями инженерной целесообразности.

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

Ответ на »сообщение 2886« (Руслан Богатырев)
___________________________
>>>Я задал вопрос, чем был обусловлен выбор ООП для представления КА по отношению к другим подходам.
КА реализовывался в рамках работы по имитационному моделированию.
Это одна из реализаций динамического объекта - "процесса".
В задаче их може быть много. Я уже писал, что работаю с ансамблями автоматов.
Поэтому объектное решение - самое то.
Если бы вся задача сводилась к конечному автомату (например транслятор), то альтернативы были бы предпочтительнее.

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

Ответ на »сообщение 2885« (Илья Ермаков)
___________________________
Разумный вариант ...

Сильное впечатление, что С.П. не прочувствовал прелесть и мощь схемы "software bus".

Ответ на »сообщение 2885« (Илья Ермаков)
___________________________

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

Добавляю свое свидетельство: на совершенно другом прикладном материале у меня произошла точно такая же эволюция: от мучений с наивным выстраиванием иерархий "объектов" к организации посредством этой самой "software bus" (термин AVC).

Полегчало сильно, я бы сказал, принципиально.

Ответ на »сообщение 2885« (Илья Ермаков)
___________________________
Разумный вариант, если удается свести схему поведения объекта к набору обработчиков событий. Довольно часто возникают случаи, когда реакция на события связана с изменением состояния всего объекта т.е. обработчик события должен знать с каким именно объектом имеет дело. И тогда отделять его от соответствующих структур данных бессмысленно: если уж это "реакция кенгуру на рев вертолета", то это должен быть метод объекта "кенгуру".
Когда удается выделять инварианты поведения, я конечно это делаю.
Когда удается обойтись без наследования, например в случае с конечным автоматом, я тоже это делаю.
Хотел только заметить, что удается не всегда.
Повторюсь: ООП - инструмент для сложных задач и очень трудно объяснять его необходимость на простых примерах.