Ответ на »сообщение 2905« (Alexey Veselovsky)
___________________________

Предположим что у нас есть некая Оберон-ОС, и я, её пользователь, имею некую программу А (представленую каким-то множеством модулей), предположим выходит новая персия программы А (А'), естественное желание пользователя (ака меня) поставить новую версию программы и сравнить её со старой.

Если Вы хотите сравнить старую программу (приложение) с новой, то надо сначала разобраться, что есть программа в Обероне: это совокупность модулей (системных, библиотечных и "доморощенных"). Давайте определимся: что было подвержено изменениям: только "доморощенные" или еще и другие? Изменение системных сродни изменению релиза ОС. Изменение библиотечных -- изменению "контекста" приложения. Если мы говорим только о "доморощенных" (модулях приложения), то главная проблема, как я понял, конфликт имен. Вывод: либо надо разносить в разные операционные пространства (как разные EXE поверх Windows, или разные Оберон-машины на одном компьютере), либо решать проблему с именами.

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

Возможно немного не в тему, но такой вот вопрос по модулям - в Обероне декларировано что может быть представлено(загружено) не более одного экземпляра модуля одновременно. Модули видимо различаются только именами. Предположим что у нас есть некая Оберон-ОС, и я, её пользователь, имею некую программу А (представленую каким-то множеством модулей), предположим выходит новая персия программы А (А'), естественное желание пользователя (ака меня) поставить новую версию программы и сравнить её со старой. Но, проблема в том, что модули у А' называются все точно так же как и у А, соответственно не выгрузив старую программу я не смогу загрузить новую.... По моему в этой ситуации есть что-то неправильное...

Видимо для модулей тоже надо вводить какие-то namespace, области видимости модулей. Какой-то реестр модулей... Ну или хотя бы использовать банальную структуру файловой системы в качестве (тут текущий неймспейс - текущий каталог где модуль лежит). Но в любом случае тогда синтаксис директивы IMPORT будет уже несколько иной...

Ответ на »сообщение 2903« (Руслан Богатырев)
___________________________

ООП тесно связано с ОО-проектированием и ОО-моделированием (модель – проект - система). В действительности, ООП -– это перенос высокоуровневых проектных понятий на уровень реализации.

Привлекательность ООП связана с тем, что оно оперирует привычными нам понятиями реального мира. Существительные (подлежащие) отображаются на объекты, глаголы (сказуемые) на методы (сообщения), прилагательные (определения) -– на атрибуты (поля). Что может быть проще? Между объектами реального мира можно установить различные отношения (из которых has-a и is-a -– самые распространенные). В результате программирование сводится к моделированию -– построению модели в "терминах задачи". Т.е. налицо проблемно-ориентированный подход. Казалось бы, какие проблемы? Чего еще искать?

Задумаемся, где лучше всего теоретически должно работать ООП? Правильно. Там, где модель максимально приближена к бытовому восприятию. Где есть устоявшееся понимание видов объектов (классов) и их отношений (наследование). К чему приводит перенос ОО-решений напрямую на ООП? К переходу в сферу распределенного (по объектам) состояния системы и тотальной асинхронности операций, которые распределены, выполняются в контексте иерархии наследования с учетом различных соглашений и умолчаний. "Анархия" управления взамен диктатуры императива. Распределенность и асинхронность -– предпосылки для максимального распараллеливания (что замечательно). В этом плане нет оснований ставить ООП на одну доску с императивным программированием. Здесь в общем случае нет последовательности команд: есть море асинхронных сообщений, обрабатываемых асинхронно. В то же время, платой за эту асинхронную гибкость ООП является комбинаторный рост сложности. Она начинает становиться неуправляемой, выходит из-под контроля.

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

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

Вот и получается, что ОО-проектирование/ООП обычно замечательно работает в руках аналитика/программиста, блестяще знающего данную предметную область (и специфику проекта), но в других случаях хромает. Как говаривал в известном мультике Винни-Пух: "Я конечно могу, но у меня пpавильнописание хpомает. Оно хоpошее, но почему-то хpомает".

Ответ на »сообщение 2902« (Руслан Богатырев)
___________________________

В чем же недостатки модульного программирования? Очевидно, они являются продолжением его достоинств.

Модули мыслятся как "железячные" сущности (черные ящики), которые имеют блок подключения и пульт управления (интерфейс, "провода" экспорта-импорта). Можно вынуть один блок, вставить другой, если только он соответствует прежнему интерфейсу. Ну и, разумеется, не забыть переключить провода (динамическая загрузка-выгрузка модулей). Гибкость (расширяемость, реконфигурируемость) обусловлена заменой напаянных межклассовых проводов "наследования" на шины обмена сообщениями.

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

Если следовать предлодженной ассоциации с аппаратурой, то у модулей (равно как и у классов) отсутствует формальная "инструкция по эксплуатации" -- спецификация протоколов вызова процедур/методов. Это -- ахиллесова пята существующих реализаций обоих подходов (но не самих подходов). Хотя некоторые подвижки имеют место быть.

Ответ на »сообщение 2901« (Руслан Богатырев)
___________________________

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

Информационное сокрытие дало основу для деления данных и кода на абстрактный (interface, definition) и конкретный (implementation) контейнер. Инкапсуляция позволила связать данные с кодом по их обработке. Этих понятий было достаточно для модульного программирования и ADT (абстрактный тип определяется названием и набором операций без раскрытия внутренней структуры данных и деталей реализации операций).  При этом он позволял решать задачи как ориентированные на функционал (operation-centric), так и ориентированные на данные (data-centric). Что отсутствовало? Установление отношений между строительными блоками (модулями и ADT), отношений более сложных, чем просто включение и экспорт-импорт.

Система Smalltalk обозначила начало эры message-ориентированного программирования. Сообщения можно было посылать между сущностями, которые при этом реагировали на них изменением данных, выполнением операций и отправкой новых сообщений. Интерпретация сообщений выполнялась путем связывания сообщений (динамически, во время выполнения) с операциями на основе информации о принадлежности сущности (объекта) определенной категории (классу). Между классами устанавливалась зависимость, которую довольно неверно назвали иерархией наследования. На практике (с учетом связей типа has-a, uses-a, is-a)  это не дерево, а граф.

Как несложно догадаться для графа отношений (классификации) совсем не обязательно использовать понятие класса, который нагружен информационным сокрытием, инкапсуляцией, наследованием и динамическим связыванием. Достаточно расширяемого record-типа. А связывание можно осуществлять не единым диспетчером (как в Smalltalk) и не таблицами методов (как в подавляющем большинстве языков), а многочисленными распределенными диспетчерами (как в Оберонах). Эти диспетчеры (message handler) оперируют понятием сообщения, которое представляется в виде расширяемой записи и реагируют на известные им сообщения, игнорируя неизвестные. Как упоминал Гуткнехт, это чисто инженерное решение, взятое из сетевого оборудования – формируется (родовая) шина пакетов данных (сообщений, message records), которая устанавливает канал коммуникации между сущностями (объектами).  Коммутация при этом многоуровневая: message-method (в обработчиках сообщений) и method-procedure (в процедурных полях записей). В дополнение к этому т.н. связанные процедуры, введенные в Oberon-2 и КП, обеспечивают традиционную модель коммутации, принятую в других ОО-языках.

Что в результате такого решения получилось? Разделение концепций в Оберонах позволяет ими оперировать более гибко и эффективно исходя из специфики решаемых задач. Модуль (module), тип (type), record-расширение (type extension) и шина сообщений (message bus) -– вот та четверка, которая позволяет переключаться между paradigm-independent представлением (модули) и paradigm-specific (классы). Слияние всех понятий в одну универсальную сущность (класс) осложняет ее применение (специализацию) для "немагистральных" задач, где лобовая иерархия наследования и data-centric подход начинают буксовать.

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

Повторюсь: ООП - инструмент для сложных задач и очень трудно объяснять его необходимость на простых примерах.

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

Давайте попробуем немного разобраться в сути вопроса. Итак, что такое ООП? Так уж повелось, что эту парадигму определяют тройкой: инкапсуляция (encapsulation), наследование (inheritance), полиморфизм (polymorphism). И многое недопонимание в отношении Оберонов таится уже в этом безобидном с виду определении. Читая различные книги, вы увидите достаточно шаблонное заблуждение: переход к объектно-ориентированному подходу произошел от структурно-процедурного подхода. См. например, http://www.intuit.ru/department/se/tppobj/1/

В действительности, это, мягко говоря, не так.

Между этими эпохами, как показывают "археологические раскопки", была еще одна, о которой почему-то принято умалчивать. Это не эпоха динозавров. :) Это эпоха модулей и тесно связанных с ними абстрактных типов данных (ADT).  Она ведет отсчет от классической работы Дэвида Парнаса декабря 1972 г. ("On the Criteria To Be Used in Decomposing Systems into Modules"), где и вводилось понятие модуляризации (разбиения на модули) и критериев такого разбиения. Идея – проектные решения при модуляризации могут быть сделаны до того, как начнется работа непосредственно над самим модулями. Информационное сокрытие (information hiding) было определено Парнасом как важнейший критерий модуляризации. Его потом перемешали с другим понятием – инкапсуляцией (encapsulation), которая обусловливает совмещение (непосредственное увязывание) данных с кодом по их обработке без учета того, скрываются детали реализации или нет. После выхода работы Парнаса его идеи к середине 1970-х годов были воплощены в Xerox PARC в параллель с работами над Smalltalk (языки Mesa, Euclid), в MIT (языки CLU, Alphard), а к концу 1970-х -- в ETH Zurich (Modula, Modula-2) и в Министерстве обороны США (Ada).

Казалось бы, Simula и Smalltalk появились до модулей и ADT (до 1972 г.), поэтому многие специалисты считают модульное программирование и ADT пережитками прошлого. На самом деле волна ООП накрыла волну ADT и модульного программирования, заставив в угоду моде срочно перекраивать многие языки на ОО-лад. Система Smalltalk-72 претерпела несколько эволюций вплоть до самой известной – Smalltalk-80 и после ряда публикаций (прежде всего, в BYTE) стала восприниматься не просто как игрушка с пользовательским интерфейсом, а как самостоятельное направление в конструировании программ разного уровня сложности. Реальный старт ООП состоялся с выходом C++ (C with Classes, AT&T Bell Labs, 1983), Objective C (в Apple и проекте NeXT, 1986) и Object Pascal (Apple, 1986).

Надо сказать, что работе Парнаса предшествовала работа Вирта "Program Development by Stepwise Refinement" (апрель 1971 г.). В ней уже прозвучали очень важные моменты: программирование – это не кодирование, одной интуции и владения языком маловато, требуется развивать конструктивное мышление, опирающееся на методологию пошаговой конкретизации (stepwise refinement) в проектировании и конструировании программ. "Степень модульности при такой декомпозиции определяется простотой/сложностью, с которой программа может быть адаптирована к изменениям, к расширениями в целевом назначении или к изменениям в среде исполнения (язык, компьютер)" – Н.Вирт.  Я уже ранее приводил ссылку на работу Дэвида Парнаса "Software Aging" ("Старение программного обеспечения", 1994 г.), где в устах идеолога модульности и информационного сокрытия мысль Вирта спустя два с лишним десятилетия обрела еще большую отчетливость.

Большой плюс модульного подхода в проектировании и реализации –- это использование принципа "черного ящика" (black box), внутри которого может быть безболезненно воплощен любой подход (ООП, ФП и т.д. и т.п.). Безболезненность определяется "тупостью" ящика, который не привносит (не навязывает) посторонних деталей (классов, фукнкций и т.п.), а разбивает проект на "обозримые" сущности-контейнеры.

>>> ООП - инструмент для сложных задач и очень трудно объяснять его необходимость ...
Точнее инструмент для задач средней сложности, для которых удаётся мысленным
взором с самого начала охватить её всю и создать удачную иерархию классов.
Когда же задача усложняется и развивается так, что меняется первоначальная
концепция, то мы получаем зубную боль под коленкой и в прочих местах.

"Убежать и спрятаться от вертолёта" может потребоваться и для запаниковавшего
солдата и для того, у кого боеприпасы кончились и для зулусов, которым ты везёшь
гуманитарку. Даже пылевые облака и брызги воды некое аналогичное поведение
проявляют, а оно уже инкапсулировано в кенгуру как стрельба в солдате!

Хотя в первоначальном глюке патроны надо было бы отобрать у кенгуру - всего и делов :)

Тащить ООП с наследованием в Оберон это как поливать икру кетчупом.
Оно можно, но какой смысл тогда в модульности?

Понравилась мысль в презентации по ссылке GeniePro:
"From the structure of the data, we can derive the basic structure of the program".
В ООП, вместо этого, структура тянется из иерархии первоначально построенных
классов, которая хороша пока всё статично.

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

В ответ жду такого же анализа по модульному подходу :)

Ok. Договорились. :)

Ответ на »сообщение 2897« (Руслан Богатырев)
___________________________
>>>Можете ли Вы сформулировать границы применимости ОО-проектирования и ООП исходя из своего опыта и своего класса задач? Так где же его недостатки и какими подходами/инструментами их можно нивелировать?
Хорошо, попробую. Правда быстро не получится, аккуратные формулировки требуют времени.
В ответ жду такого же анализа по модульному подходу :)

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

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

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

Можете ли Вы сформулировать границы применимости ОО-проектирования и ООП исходя из своего опыта и своего класса задач? Так где же его недостатки и какими подходами/инструментами их можно нивелировать?