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

Вероятно, ООП вполне сводится к возможности замены абстракции ее (множественными) реализациями.
В этом смысле и открытые массивы -- пример ООП.

Да неужели? И что же тогда ООП в Вашем понимании? Если абстракция имеет несколько реализаций, это совсем необязательно ООП.

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

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

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

Расширяемые типы Оберона направлены именно на это, а не на ООП. Их к ООП просто приткнули сначала в Обероне-2, а затем в Компонентном Паскале.

Вероятно, ООП вполне сводится к возможности замены абстракции ее (множественными) реализациями.
В этом смысле и открытые массивы -- пример ООП.

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

Добавление новых свойств не сводится к расширению интерфейса.

Парирую Вам такой фразой: "Добавление новых свойств не сводится к ООП".

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

Ответ на »сообщение 4561« (Посторонний В)
___________________________

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

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

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

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

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

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

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

Поскольку в борьбе за чистоту “базара” жертвой пала важная мысль, повторю ее в третий раз.

Удивляюсь наивности некоторых участников форума. Не будет индустрия заниматься Обероном. Это надо усвоить. Раз и навсегда. Те, кому он действительно нужен, спокойно его используют и сильно не парятся. Если есть голова на плечах и руки не повязаны начальством. Спасибо за внимание.

Т.к. осмысленные обобщения насчет "индустрии" делать трудно (последний раз, во всяком случае, не получилось), предлагаю более конкретный пунктик.

В свежевыложенном любопытном тексте адцкого специалиста Рыбина (ВМК МГУ) на орловском сайте есть такие слова:

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

Интересно в педагогических целях перетереть это в свете ОТ. В этом свете ответ Рыбина тоже не вполне удовлетворителен (надо, конечно, дать скидку на небрежность спонтанной устной лекции, но, с другой стороны, мысль его, очевидно, хорошо обдумана в процессе педагогики).

Нужно бы во-первЫх подчеркнуть, что это еще один способ реализации принципа DIVIDE ET IMPERA, позволяющий добиться независимой эволюции частей программы.

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

(Тут проявляется одно из преимуществ Оберона над Адой как основы базовых курсов программирования 8)))

В-третьих, ОТ добавляют штрих: в язык вводится ровно такая доза этого "лекарства", которая позволяет сохранить тонкость/прозрачность языкового слоя над слоем железным.