Ответ на »сообщение 2942« (горемыка)
___________________________

Ура! Ура! Ура!

А Вы че хотели-то? Чудес во вводном курсе? Объяснения циклов через ... астрофизический объект?

И если Вы забыли: лекция -- 2 акад. часа, компьютерный класс -- 7 часов. В неделю. Ну и так далее.

Но я рад, что Вы рады.

Ответ на »сообщение 2944« (Сергей Перовский)
___________________________
...то проще делать новую систему, чем модернизировать существующую.
А вас не сильно удивляет, что в 99.9(9)% случаев именно так и происходит?
И это при том, что уже выросло почти два поколения программистов и разработчиков, для которых ООП не "что-то новое", под которое нужно пересматривать и ломать свои мировосприятия и методики, а что-то, что "лежит готовое на тарелочке" ( да не одно, а в разных видах и упаковках - тока выбирай! )...

Ответ на »сообщение 2938« (Как слышно? Приём!)
___________________________
>>>Горизонтальные связи вводятся вопреки парадигме наследования.
>>>Это вынужденное и кривое отступление, диктуемое сущностью решаемой
динамической, меняющей акценты и растущей с годами задачи.
А кто сказал, что связи наследования должны быть единственными связями между объектами и классами? Этак ни одной системы не построить.
Отношение наследования это отношение между большей и меньшей абстракцией.
Парадигма наследования состоит всего лишь в том, что одинаковые части должны быть сделаны однократно.

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

Ответ на »сообщение 2938« (Как слышно? Приём!)
___________________________

Так вот вопрос - если ООП в Обероне не дань моде и мейнстриму, то почему же не всё на Generic Message Handler и "мягком автобусе" :) ?

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

В общем, вполне очевидно: желательно максимум информации о задаче выражать статически, но это вносит "жесткость". Вот и нужно сбалансировать эти вещи.

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

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

А материалы по Вашему курсу где-нибудь доступны вне МГУ? ...

Где-нибудь, кому-нибудь... да.

Было бы любопытно сравнить...

Вот специально для Вас самая средняя (по номерам) лекция осеннего семестра:
http://www.inr.ac.ru/~info21/08.pdf

Ура! Ура! Ура!

Ответ на »сообщение 2938« (Как слышно? Приём!)
___________________________
>>> связей типа has-a, uses-a, is-a)  это не дерево, а граф.
А кто постулировал вырождение графа отношений is-a в дерево ?!?!?!?!?!?!?!?!?!?!?!?!?!?!
ЗЫ сразу предупреждаю, что б лишний раз не напрягало, что я не имею в виду множественное наследование...

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

"Магистрально-модульное программирование" (ММП)
Шино-монтаж или Модубас. :)

>>>Щас подумаю и выдам!
А чего думать.
Bus - это "шина", "магистраль".
Module - это "модуль"
Значит...
"Магистрально-модульное программирование" (ММП)
ММП vs. ООП

Ещё короче:
>>> ООП - инструмент ... трудно объяснять его необходимость ...
Здесь не только "currently fashionable".
Jack хорошо сказал: "за базовые классы опытного специалиста",
"за расширения - команду джуниоров". В результате и спец не всё делает
(есть резон отнять у него "вот стока денег") и джуниоры сыты и "серьёзная
команда" в наличии и без менеджера с его штучками никуда не деться.
То есть ООП широко распространён как удачный менеджерский приём
для проекта "деньги-софт-деньги", а сейчас эпоха или царство менеджеров.

Хотя структуре проекта в техническом и логическом смысле он, на мой взгляд,
только вредит искусственной топологией связей.

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

>>> Между классами устанавливалась зависимость, которую довольно
>>> неверно назвали иерархией наследования. На практике (с учетом
>>> связей типа has-a, uses-a, is-a)  это не дерево, а граф.

Э, нет! "Померла так померла!" :) Это Вы слишком ловко!
Горизонтальные связи вводятся вопреки парадигме наследования.
Это вынужденное и кривое отступление, диктуемое сущностью решаемой
динамической, меняющей акценты и растущей с годами задачи.
Всё-таки это дерево с подпорками, подвязками, привоями и заплатками.
Назвать это графом - завуалировать имеющиеся серьёзные недостатки.

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

Так вот вопрос - если ООП в Обероне не дань моде и мейнстриму, то
почему же не всё на Generic Message Handler и "мягком автобусе" :) ?

Тут нужен хороший термин (слоган нужен, как ООП).
Щас подумаю и выдам!

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

А материалы по Вашему курсу где-нибудь доступны вне МГУ? ...

Где-нибудь, кому-нибудь... да.

Было бы любопытно сравнить...

Вот специально для Вас самая средняя (по номерам) лекция осеннего семестра:
http://www.inr.ac.ru/~info21/08.pdf