Илья Ермаков писал(а):
alexus писал(а):
И его "довесок" в виде ООП - это не потребность Оберон, а нечто вроде... "Хотите ООП?.. Нате вам... только отвяжитесь"... Что можно сделать нового с помощью ООП в Оберон, чего бы нельзя было сделать без него [без ООП]?..
Вот и нет. ООП позволило делать динамически расширяемые системы.
Объявите на процедурном языке интерфейсы и расширяйте любую систему на процедурном языке... Мы писали свою первую систему (для металлургов) на PC-XT (среда Turbo Pascal) именно так (включая overlay's и динамически подгружаемые библиотеки). Никаких объектов не было, а систему расширяли (уже без нас) около десятка лет. Динамические библиотеки и были теми самыми компонентами...
Илья Ермаков писал(а):
Собственно, Вирт и сделал язык для написания своей новой ОС. Компонентное программирование, как течение в индустрии, началось как раз с того, что Вирт включил ООП в Оберон. Добавил к динамической модульности полиморфизм (динамическое связывание).
Полиморфизм на основе интерфейсов... гораздо богаче полиморфизма на основе наследования. Поэтому оценить выбор Н.Вирта положительно, увы...
Илья Ермаков писал(а):
Что из этого вышло, мы знаем, например, по работам Шиперского:
http://oberoncore.ru/library/start (Object-orinetation in operation systems и Component Software Beyond Object-Oriented Programming).
У нас про это хорошую статью написал Сергей Юрьевич Губанов:
http://oberoncore.ru/articles/gubanovСтатья С.Ю. Губанова замечательная, хотя и не бесспорная. Например, он пишет
С.Ю. Губанов писал(а):
Программирование модульных систем, вообще говоря, не требует обязательного использования объектно-ориентированного подхода и наоборот. Однако, одновременное использование этих двух подходов для построения расширяемых систем привело к появлению новой парадигмы программирования. Дело в том, что ООП, в его наиболее распространённой трактовке, основано на понятии наследования. При совместном использовании ООП и модульности возникнет межмодульное наследование, но оно является препятствием к взаимозаменяемости модулей от различных производителей. Если часть типа определена в одном модуле, а другая часть типа — в другом, то весьма проблематично модуль с базовым типом поменять на аналогичный модуль от другого производителя из-за возможных тонких различий в реализации. В 1995 году, профессор Клеменс Шиперски (Clemens Szyperski) сформулировал основные положения Компонентно-ориентированного подхода (КОП) через ограничения, накладываемые на модульный подход и на ООП для их непротиворечивого одновременного сосуществования («Component-Oriented Programming A Refined Variation on Object-Oriented Programming», The Oberon Tribune, Vol 1, No 2, December 1995). Цель КОП — построение расширяемых (в полном смысле этого слова) систем с помощью модулей и ООП. Таким образом, КОП находится (по мнению Шиперского) «За пределами ООП» (так называется его уже дважды изданная за рубежом книга-бестселлер, к сожалению, до сих пор не переведённая на русский язык). Фундамент КОП образуют: полиморфизм, позднее связывание, настоящая инкапсуляция, полный контроль безопасности со стороны среды времени исполнения.
Замените слово "полиморфизм" на "интерфейсы" и исчезнет "объектность"... Но дело не простой в подмене понятий, а... в последовательности (разноуровневости) проектирования. Верхний уровень декларирует интерфейсы (что ему нужно от нижнего уровня), а нижний уровень группирует интерфейсы и формирует... описание модулей или классов. И т.д.
Илья Ермаков писал(а):
Конечно, но это не уровень моделирования, это более низкий уровень компоновки технической системы. Но лучше решить хорошо проблемы одного уровня и оставить другой людям на самостоятельное решение, чем получить неважное решение сразу обоих уровней.
Вот об этом-то и речь...