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

Техническое применение ООП в Оберонах и не только я затрагивал в статье "Некоторые идеи архитектуры Оберон-систем":http://oberoncore.ru/index.php?option=c ... &Itemid=22
Она будет, наверное, сложноватой, что непонятно - спрашивайте, потом что-то самое главное сможете взять для лекций.

А ниже еще - кое-что из истории ООП в изложении одного знающего товарища с оберонских форумов DelphiKingdom:
> -- Цитата:
> Дело в том, что попыток сформулировать, что же такое Оберон-технология (прошу заметить не язык и не система, а именно вынесенная в заголовок технология) было тут не мало. Но я уловил единственное реальное отличие от других систем: базовое понятие модуля, как единицы языка, единицы компиляции и единицы загрузки в одном лице. Да еще и с автоматическим динамическим контролем корректности вызовов.В чем суть Оберона я уже сформулировала: модуль + расширение RECORD-типа. А динамика загрузки-выгрузки - побочная вещь.Синтаксис языка отличается замечательной цельностью.Именно тот случай, когда знание принципов освобождает от знания фактов.Тони Хоар, один из ближайших друзей и соратников Вирта, называл это концептуальной экономией (conceptual economy). И наряду с надежностью и эффективностью считал очень важным свойством языка программирования.Готов выслушать Вашу формулировку Оберон-технологии.Боюсь, к этому не готова. Есть несколько разных Оберон-языков. Они исповедуют несколько отличные вещи. Поэтому корректнее было бы говорить об Оберон-технологиях, во множественном числе. И не удивляться, что в каких-то моментах они могут противоречить или вступать в конфликт друг с другом. По крайней мере, для пользы дела удобнее считать именно так, пока убедительно не доказано обратное.ООП возникло дважды из двух разных классов задач.Первый раз это было как раз имитационное моделирование - в Симуле67 было введено понятие класса и объекта, имеющего не только поля, но и схему поведения.Если позволите, я бы это прокомментировала. В основе ООП лежит концепция класса. Откуда возникло это слово и сама идея? Разумеется, Smalltalk не был тут первопроходцем. Первым языком, в котором слово class, обозначающее ту концепцию, которая близка нашему нынешнему понимаю ООП, была Simula 67. Здесь Снегурочка с Вами готова согласиться. Но дело в том, что идея класса была сформулирована и реализована несколько раньше - в языке Simula I. Там уже были activity (классы) и process (объекты). Кристен Нигаард и Оле-Йохан Дал еще тогда заложили идею порождения объектов, каждый из которых суть данные плюс связанные с ними операции, правда, тогда еще без наследования. В 1965 г. в ALGOL Bulletin вышла важнейшная работа Тони Хоара, которая называлась просто "Record Handling". В ней Хоар обобщил опыт других языков и предложил идею record class, объединив запись - record (известной по  PL/I и COBOL) со ссылкой - reference (она была предложена Виртом в 1965 г. в его первом языке Euler и двумя годами ранее в языке CPL из английского Кембриджа).Как признавались Нигаард и Дал в своих воспоминаниях о создании Симулы, именно осенью 1966 г. они тщательно изучали работы Хоара (вслед за первой вышла в марте 1966 г. и Further Thoughts on Record Handling). Они искали способ "прикрутить" понравившуюся идею record class к своей Симуле. И пришли к выводу, что ее можно сформулировать как process class, убрав слово process. Т.е. оставить просто class. Правда, reference там были в неявном виде.В 1972 г. в Советском Союзе в изд-ве "Мир" вышел сборник "Языки программирования", где были опубликованы переводы докладов на Летней школе NATO по языкам программирования, которая прошла в 1966 г. в Виллар-де-Ланс (Франция). Если сможете его раздобыть, рекомендую внимательно изучить работу Хоара "Обработка записей" (Record Handling). Несмотря на не очень хороший перевод почитать очень даже стоит. Работа занимает примерно 60 страниц. Из нее понятно, откуда росли ноги ООП и что закладывалось в основу той самой Симулы-67, от которой обычно и принято вести отсчет эре ООП. В том же сборнике есть и столь же объемная статья Оле-Йохана Дала о Симуле. Сам Дал вместе с Нигаардом в качестве источника идей Симулы-67 упоминали именно эту тройку работ Хоара (включая и его доклад на школе NATO).Второе открытие ООП связано с задачей построения оконного пользовательского интерфейса и языком Смолтолк. На этой задаче большинству студентов объясняют принципы ООП.Собственно, это детище Алана Кея и дало реальный импульс моде на ООП, которая переросла потом во всеобщую "ООПсовизацию" программирования. Алан Кей, в отличие от большинства из нас, хорошо был знаком с ранними работами Никлауса Вирта, и с большим интересом относился, в частности, к тому же языку Euler, где была заложена динамическая типизация в рамках алголоподобного языка.Поскольку сей факт известен очень немногим, приведу точные цитаты (дело было в апреле 1993 г. в американском Кембридже на конференции HOPL-II, сразу после доклада Вирта об истории разработки Паскаля):Allen Kay: Your thesis and Euler were going in a pretty interesting direction. Why did you go back to more static languages?Niklaus Wirth: For a thesis topic you have to do something that is new and original, you are expected to explore new ways. Afterwards, as an engineer, I felt the need for creating something that is pragmatic and useful.В основу Паскаля были положены идеи Хоара о record handling. Но даже без намека на ООП. В Modula и Modula-2 вошли идеи Симулы по моделированию на основе процессов, хотя облечено это было в концепцию модуля из языка Mesa. В Обероне Вирт по сути вернулся к первоистокам: record + reference (но уже и ссылки на procedure) и дали фундамент для ООП без использования самого ООП. Круг замкнулся.Таким образом, Оберон помимо того, что был квинтэссенцией Паскаля и Модулы, вобрал в себя идеи Хоара, Euler и Simula. Ответ на >сообщение 1771< (AVC)___________________________Насчет модуля, кажется, понятно.В действительности, есть немаловажный нюанс при "разрезании" класса на модуль и расширяемые типы. Для класса можно порождать сколь угодно много экземпляров - объектов. В случае модуля - сам модуль может быть только один.А в чем принципиальное различие между расширением типа и наследованием?Вопрос непростой. Помимо чисто "идейно-психологического" различия (математическое понятие против социально-антропологического) есть и кое-что еще. Наследование (inheritance) устанавливает отношение наследования (нерефлективное, несимметричное, но транзитивное) между двумя сущностями - классами. Строго говоря, из наследования не вытекает, что "наследник" должен в точности сохранять структуру "наследодателя", лишь дополняя ее, и безболезненно подменять "наследодателя" везде, где тот ранее использовался.У Вирта расширение типа (type extension) строится на понятии подтипизации (subtyping). Есть тип (расширяющий тип), есть его подтип (расширяемый тип). Принцип подстановки (Liskov substitution principle), выдвинутый Барбарой Лисков в 1993 г., говорит о том, что S является подтипом типа T, если для любого истинного q(t) следует, что истинно и q(s).Если не ошибаюсь, в Eiffel при наследовании можно не только модифицировать, но и даже удалять свойства, унаследованные от базового класса. В C++, например, есть приватное наследование (private inheritance), нарушающее принцип подстановки и подтипизацию.Вообще говоря, имеет смысл воспринимать type extension в Обероне с позиции record class Хоара, а не process class Нигаарда-Дала. Здесь больший уклон в данные, а не в операции. Хотя при наличии в Обероне процедурных типов, через которые и реализуются методы, никто не запрещает все перевернуть с ног на голову.СнегурочкаОтвет на >сообщение 1856< (Сергей Перовский)___________________________объектный подход удобен при создании сложных систем, имитационное моделирование первым потребовало создания ОО инструмента потому, что занималось только сложными системами. Потребовалось еще 25 лет для осознания, что ООП пригодно для большинства сложных систем, что это не узкоспециализированный инструментарий для отдельного класса задач.А следует ли из этого, что ООП пригодно для большинства простых систем? А если нет, то почему языки полностью "погружают" в ООП, как, например, Java?Что касается понимания областей применимости ООП на заре его появления, то не скажу за Нигаарда и Дала, которые действительно в основном работали с имитационным моделированием, но по Хоару это не совсем так (цитирую по работе Record Handling из Летней школы NATO 1966):Фундаментальная особенность нашего понимания мира заключается в том, что мы систематизируем свой жизненный опыт, представляя его в виде отдельных понятий или объектов (столы и стулья, банковские займы и алгебраические выражения, многочлены и люди, транзисторы и треугольники и т.п.), и наше мышление, язык и действия основываются на обозначении, описании и манипуляциях с этими объектами, с каждым в отдельности или в связи с другими объектами. Если мы хотим решить задачу на компьютере, то часто нужно построить в нем модель того аспекта реального или воображаемого мира, к которому будет применяться алгоритм решения задачи. В такой модели каждый объект исследования должен быть представлен некоторой величиной, которая "доступна" программе и может быть использована ею в процессе работы. Назовем такую величину записью (record). Каждый объект, представленный в запоминающем устройстве компьютера в виде записи, будет обладать одним или более атрибутами (attributes), с которыми и приходится иметь дело при решении задачи. Обычно эти свойства выражаются простыми значениями соответствующего типа. <...>Объекты реального мира удобно классифицировать с помощью некоторого числа взаимно исключающих классов (classes), причем каждый класс обозначается некоторым собирательным именем, таким, как "человек", "банковский заем", "выражение" и т.д. <...>Если программа выполнялась уже в течение некоторого времени, то может случиться так, что требуется сегмент расширения, а единственные доступные сегменты находятся в опасной близости к магазинной памяти. При подобных обстоятельствах целесообразно воспользоваться процедурой автоматического собирания свободных участков памяти, подобной той, которая описана Маккарти (1960).<...>В реальных условиях часто разбивают класс объектов на несколько взаимно исключающих подклассов (subclasses). Например, класс позвоночных можно разбить на такие подклассы, как млекопитающие, пресмыкающиеся, птицы и рыбы...Класс записей (record class), который разбивается на подклассы, называется составным; класс или подкласс, который не является составным, называется простым. Ссылочные переменные могут, согласно их описаниям, указывать на все записи составного класса или же их область действия может быть ограничена каким-то одним определенным подклассом.<...>Если областью действия ссылочной переменной является, согласно ее описанию, составной класс, то программист может пожелать на некотором этапе выполнения программы определить, какому из возможных подклассов фактически принадлежит запись, на которую ссылается в настоящее время эта переменная. Этого можно достигнуть с помощью специальной конструкции, называемой различитель класса записи (record-class discriminator). <...>Расширение определения знаков операций для действий над ссылками на записи новых типов называют перегрузкой (overloading). Впервые идея перегрузки была предложена Дж.Маккарти...Как видно из этого текста, 40 с лишним лет назад Хоар достаточно подробно описал идеи ООП, при этом ни о каком ограничении сферой имитационного моделирования речи не идет. Хоар еще указал в своей работе такие языки обработки "ООП"-записей, как Lisp, Simula I и PL/I.Вирт в Паскале интерпретировал идеи Хоара через указатели, записи и вариантные записи. Спустя полтора десятка лет после Паскаля он пришел к выводу, что это надобно делать через type extension с запретом вариантных записей (лобовой реализации составных классов). В остальном и автоматическая сборка мусора, и наследование, и полиморфизм (без явного использования этих терминов) были Хоаром озвучены. Было это до появления Simula 67.