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

Ответ на »сообщение 2751« (AVC)
___________________________
Наследование реализации полезно и используется в "каркасе", т.е. когда разработчику предоставляются заготовки с некоторым поведением, которые он достраивает под себя. В ББ такими заготовками являются базовые графические типы - Views.View, Containers.Container, Controls.Control. Однако заготовки, хотя и имеют некоторые конкретные реализованные процедуры, объявляются как ABSTRACT, и создать их экземпляр невозможно.

Такие типы иногда называются полуабстрактными (semi-abstract).
И правда, я забыл о них сказать, а они иногда играют важную роль (когда разработчик базового класса хочет обеспечить некую базовую функциональность).
Например, с помощью полуабстрактных типов можно формировать расширяемые программные каркасы, а также включить в библиотеку реализацию того или иного паттерна проектирования (почему-то JoS уверен, что это невозможно, но это на его совести).

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

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

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

>>>Поэтому, ИМХО, рано считать тему модульности достаточно хорошо освещенной в литературе.

Конечно, правильнее было сказать: я еще недостаточно знаком с такой литературой. :)

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

Спасибо за содержательный ответ.

>>>...было бы лучше, чтобы по возможности участники дискуссии познакомились с материалами по этому направлению (модульное программирование). Можно по соотв. разделу в EuroProg.ru и по списку новых поступлений. Конкретика по языкам модульного программирования Mesa (с которого делалась Modula-2), Cedar (с которого делался Оберон), CLU, Alphard, Euclid появится в ближайшие дни.

Прочту (и другим советую).
На текущий момент я прочитал несколько статей Шиперски и работу Crelier по раздельной компиляции.
Статьи Шиперски достаточно понятны. Он обычно пишет о том, что не все сущности делятся на классы без остатка. Например, глобальные константы и переменные, а также инварианты, относящиеся к взаимодействию двух и более классов. Если же ввести в язык такую конструкцию, как модуль, все встает на свои места.
Это действительно хорошие статьи, но иногда создается впечатление, что они сводятся к разбору патологических случаев ("парад уродов" ООП).
Работа Crelier очень интересна, но носит сугубо технический характер (и правильно).
Поэтому, ИМХО, рано считать тему модульности достаточно хорошо освещенной в литературе.

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

>>>Из сказанного вытекает и главная слабость (уязвимость) модульного программирования в подходе Оберонов -- расширение через границы модулей.

Похоже, это именно то, что отталкивает Сергея Перовского.

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

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

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

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

Из сказанного вытекает и главная слабость (уязвимость) модульного программирования в подходе Оберонов -- расширение через границы модулей.

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

Можно ли развить ее подробнее?

Можно и поподробнее. Но было бы лучше, чтобы по возможности участники дискуссии познакомились с материалами по этому направлению (модульное программирование). Можно по соотв. разделу в EuroProg.ru и по списку новых поступлений. Конкретика по языкам модульного программирования Mesa (с которого делалась Modula-2), Cedar (с которого делался Оберон), CLU, Alphard, Euclid появится в ближайшие дни.

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

В отличие от сильных связей между классами слабость этих связей между модулями обусловлена:
1. В модуле может быть размещено несколько классов, а не один (концепция No Paranoia).
2. Совокупность модулей в большей степени стремится к линеаризации (меньшему числу уровней и схемой, близкой к линейной), нежели классы, поскольку основное назначение классов -- иерархия наследования. У модулей такой сверхзадачи нет.
3. Модули более "тупые" в концептуальном смысле, нежели классы. Это просто блоки разбиения системы на компоненты безотносительно наследования свойств.
4. Модули в большей степени соответствуют "железячным" принципам коммутации аппаратуры: четкие разъемы, позволяющие вынуть один и на его место поставить другой, даже по ходу работы системы.
5. Модули не являются типами данных и всегда имеют одного "физического" представителя.
6. Модули (в трактовке Вирта, начиная с Оберона) не допускают вложенности, что упрощает схему управления областями видимости и снимает многие проблемы с программиста.
7. Модули есть средство унификации главных строительных единиц проектирования, спецификации, документирования, кодирования, исполнения, включения/замещения/развертывания(компонент).

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

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

Думается, это центральный момент.
Мне кажется, в нашей ветке эта мысль еще не высказывалась в такой простой и легкой для усвоения форме.
Можно ли развить ее подробнее?

Если связь экспорта-импорта слабее наследования, то многое проясняется.
Но так ли это?
Ведь иерархия модулей в некоторых пунктах подобна иерархии классов: обе статичны, обе выглядят как даг и т.п.
Кажется, главное отличие в том, что модули не наследуют друг другу, ограничиваясь отношениями импорта-экспорта.
Кроме того, модуль сам по себе не является типом, в отличие от класса.
В чем главная причина относительной слабости межмодульных связей?

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

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

А не могли бы Вы пояснить, в чем преимущество реализации ансамбля КА средствами ООП перед модульным программированием? То, что можно оформить в виде класса, я понимаю. Но зачем именно так? Ансамбли КА можно реализовывать в ФП, на Прологе, да много еще на чем. Но интересно обоснование выбора ООП для этого направления.