OberonCore

На форуме Королевства Дельфи Руслан Богатырев очень хорошо выступил со сравнением концепций модуля и класса, оценкой подхода Б. Мейера к их полному отождествлению, и т.п.:
http://www.delphikingdom.com/asp/talkto ... t=10&pNo=1

Рекомендую почитать.

Свое мнение на эту тему уже высказывал в соседней ветке:

В чем основная задача ООП? На мой взгляд - облегчить сопровождение программы. И такие вещи как наследование, полиморфизм и инкапсуляция действительно помогают в этом. Потому что в верно спроектированную ОО-систему всегда не трудно добавить функциональность или внести какие-нибудь другие изменения. Кто-то говорил, что ООП возможно не только на ОО языках. Возможно... но я слабо представляю себе полиморфизм на языке C (Ручное создание таблицы виртуальных функций?!). ОО языки облегчают сам процесс ООП. Основное понятие ООП - объект. (Вернее даже "субъект"). Мы знаем ЧТО он делает , но нам совсем не обязательно знать КАК он делает, если конечно он делает то, что мы от него ожидаем, не больше и не меньше
Например, легковой автомобиль. Мы знаем для чего он предназначен, как им управлять, какое топливо покупать, у нас есть даже права, но при этом мы можем и не знать, какие процессы происходят внутри автомобиля. Также не секрет, что автомобиль содержит в себе множество различных деталей, каждая из которых также может состоять из других деталей. Кроме того, детали нашего легкового автомобиля врядли подойдут другим объектам, например нашей стиральной машине или холодильнику. А теперь представим, что мы конструкторы автомобиля...
Прежде чем создать автомобиль нам нужно создать детали, из которых он состоит. И вот тут возникают вопросы... Понятно, что некоторые детали мы можем взять уже готовыми. Если говорить терминами КП - из других модулей. Но некоторые придется делать самим (должен же наш автомобиль чем-то отличаться от других!) Куда разместить эти наши детали? Опять же, если говорить о КП, то тут такие варианты:
1) для каждой детали создаем свой модуль.
2) все детали помещаем в тот же модуль, где находится автомобиль.
В КП второй подход, на мой взгляд, совершенно противоречит ООП, так как детали в автомобиле взаимодействуют между собой. А объекты внутри модуля могут получать доступ к полям друг друга, скорее всего невидимым вне модуля. А детали могут быть совершенно разными. И что произойдет, когда нам придет в голову поменять какую-нибудь деталь?! Конечно, детали внутри модуля могут быть связаны друг с другом только через свои интерфейсы. Они и должны быть связаны друг с другом только через свои интерфейсы!
ООП - фактически ограничение самого себя с помощью компилятора А если ограничений нет, то нет и ООП (программирования, проектирование есть). Получается, нам нужно каждую деталь хранить в отдельном модуле. А отдельный модуль с одним экспортируемым типом в КП, чем не класс в С++?
Можно также поместить все схожие по назначению детали в один модуль. Эти детали уж точно никак не будут взаимодействовать между собой (Карбюратор и инжектор внутри одного автомобиля не уживаются ) Но где гарантия? То есть в этом плане КП ограничивает свободу - правильных решений не много.
Мне кажется, отсутствие инкапсуляции внутри модуля в КП, то есть отсутствие понятия КЛАСС - недостаток КП. Такой же, как отсутствие понятия МОДУЛЬ в С++. Чем плохо, если бы RECORD в КП аналогично CLASS или SCRUCT в С++ имел бы директивы PRIVATE и PUBLIC, действующие внутри модуля тоже?
[/b]

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

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

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

А при вашем подходе мы дойдем до абсурда. Вот конкретный пример, прямо из ББ (модуль Dialog). Создаем набор типов для работы с деревом: Tree - само дерево, TreeNode - вершина дерева. Пользователь не имеет никакого понятия о реализации этих типов, для него создается набор общих методов. Теперь приступаем к реализации - и сразу же видим, что эти два типа должны иметь полный доступ к внутренностям друг друга. Если заставить их взаимодействовать между собой через тот же интерфейс, который мы описали для пользователя, мы получим красивую, но крайне медленную и бесполезную реализацию. А теперь представьте, что мы пишем не дерево, а операционную систему. Такие группы объектов, которые работают вместе, будут встречаться сплошь и рядом. Что будем делать тогда?
Оказывается, что у каждого объекта есть две стороны - одной он обращен к пользователю, а другой - к тому узлу, в составе которого он работает. И директивы friend в С++ являются очень корявым решением этой проблемы, практически костылем, поэтому основным советом является "используйте friend, только если вы абсолютно уверены, что это нужно". Напротив, модульность в сочетании с ООП - элегантное и системное решение проблемы. ООП помогает нам анализировать предметную область и проектировать нашу систему, модульность помогает нам ее успешно и эффективно реализовывать.

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

Вышеописанная проблема, кстати, эта одна из причин, почему С++ не особенно жалуют системщики. Торвальдс и Танненбаум очень критически выссказывались по поводу использования С++ при написании ОС. Linux, QNX, ядро Windows - все это написано на голом С. Потому что если ваш с Мейером подход может себя оправдать при создании прикладных систем, то в системном программировании он безусловно пасует - либо реализация получается очень неэффективной, либо приходится постоянно обходить инкапсуляцию.

Оберон же как раз в первую очередь использовался как язык системного программирования (для прикладных задач он еще только начинает использоваться) - на нем оказалось очень удобно реализовывать операционные системы. И две промышленные системы жесткого реального времени (JBed и XOberon) тому доказательство, не считая исследовательских Oberon-1, Oberon System 3, Blue Bottle. Именно Оберон позволил использовать для ОС ООП без потери эффективности (кстати, и сборку мусора тоже).

Если хотите понять идеологию модульных языков - почитайте материалы в разделе Статьи у нас на сайте - там как раз эта тематика освещается.

Эта проблема в С++ может быть решена и без friend'ов. Просто пользователь видит только интерфейсы, а реализация (модуль в терминах С++) и внутренности.

Можно, не спорю.

Какая у Вас жуткая каша в голове...

Перед Вами типичный самоучка, да еще с довольно маленьким опытом

Ничего, самоучками были почти все, а опыт - дело наживное

Если есть желание менять детали впоследствии - то оформляйте их отдельным модулем. Кстати, очень мало программ страдает от излишней модульности.

Запоздалый коментарий:
Вот В. Лось тоже обещал мне качественный скачек в понимании ООП. И надо сказать он произошел. Перелопатил я кучу литературы по ООП и вот что я понял : лохи и лохи для лохов
это ООП. Там на самом деле никакой общепринятой точки зрения нет. Есть распростаненные мифы и куча бреда в виде например переписанных в т.н. ООП-стиле стандартных приемов программирования известных еще как "паттерны пректирования" или т.н. ОРМ (для баз данных. К смеху сказать но когдато в одой из контор директор поставил перед нами (я и мой дружок) настрочить на Firebird эволюционную БД с объектным интерфейсом. Так вот большая часть идей заложенных в ОРМ ясна была любому идиоту до появления всех этих теорий.Читая книжки по этому вопросу умиляешься до слез ). Вообщем бред и бред....

Удачно сформулировано.