Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 2946 22-02-2007 11:37 | |
Ответ на »сообщение 2942« (горемыка)
___________________________
Ура! Ура! Ура!
А Вы че хотели-то? Чудес во вводном курсе? Объяснения циклов через ... астрофизический объект?
И если Вы забыли: лекция -- 2 акад. часа, компьютерный класс -- 7 часов. В неделю. Ну и так далее.
Но я рад, что Вы рады.
№ 2945 22-02-2007 09:33 | |
Ответ на »сообщение 2944« (Сергей Перовский)
___________________________
...то проще делать новую систему, чем модернизировать существующую.
А вас не сильно удивляет, что в 99.9(9)% случаев именно так и происходит?
И это при том, что уже выросло почти два поколения программистов и разработчиков, для которых ООП не "что-то новое", под которое нужно пересматривать и ломать свои мировосприятия и методики, а что-то, что "лежит готовое на тарелочке" ( да не одно, а в разных видах и упаковках - тока выбирай! )...
№ 2944 22-02-2007 09:06 | |
Ответ на »сообщение 2938« (Как слышно? Приём!)
___________________________
>>>Горизонтальные связи вводятся вопреки парадигме наследования.
>>>Это вынужденное и кривое отступление, диктуемое сущностью решаемой
динамической, меняющей акценты и растущей с годами задачи.
А кто сказал, что связи наследования должны быть единственными связями между объектами и классами? Этак ни одной системы не построить.
Отношение наследования это отношение между большей и меньшей абстракцией.
Парадигма наследования состоит всего лишь в том, что одинаковые части должны быть сделаны однократно.
Вот, пожалуй, ограничения на применение ООП:
для использования ООП необходимо строго определить предметную и проблемную области задачи, т.е. договорится не только "про что" программа, но и "для чего";
необходимо провести системный анализ для декомпозиции системы на объекты и связи между ними;
для сходных объектов нужно выделить инвариантное ядро.
Если хотя бы один этап этой предварительной подготовки проделать не удается, использование ООП может привести к сложным ситуациям (хрупкость базовых классов и т.д.). Причин, по которым это не удается много, но прежде всего это неумение.
Таким образом, выбор ООП предполагает представление о жизненном цикле создаваемого программного продукта включая его ликвидацию при моральном устаревании в следствии выхода за пределы проблемной области. Проще говоря, если системный аналитик не предполагал такую задачу, то проще делать новую систему, чем модернизировать существующую.
№ 2943 22-02-2007 06:42 | |
Ответ на »сообщение 2938« (Как слышно? Приём!)
___________________________
Так вот вопрос - если ООП в Обероне не дань моде и мейнстриму, то почему же не всё на Generic Message Handler и "мягком автобусе" :) ?
Очень просто:
Когда часть задачи (скажем, некий мессидж) из выкристаллизовывается (вместе с пониманием задачи) настолько четко и общО, что можно выделить ее в метод без опасений, что придется менять и т.п.
Тогда использовать метод проще и выразительней (статически, а не динамически, как с "автобусом", так что необходимые проверки может сделать уже компилятор).
В общем, вполне очевидно: желательно максимум информации о задаче выражать статически, но это вносит "жесткость". Вот и нужно сбалансировать эти вещи.
№ 2942 22-02-2007 06:38 | |
Ответ на »сообщение 2937« (info21)
___________________________
Ответ на »сообщение 2934« (Geniepro)
___________________________
А материалы по Вашему курсу где-нибудь доступны вне МГУ? ...
Где-нибудь, кому-нибудь... да.
Было бы любопытно сравнить...
Вот специально для Вас самая средняя (по номерам) лекция осеннего семестра:
http://www.inr.ac.ru/~info21/08.pdf
Ура! Ура! Ура!
№ 2941 22-02-2007 05:59 | |
Ответ на »сообщение 2938« (Как слышно? Приём!)
___________________________
>>> связей типа has-a, uses-a, is-a) это не дерево, а граф.
А кто постулировал вырождение графа отношений is-a в дерево ?!?!?!?!?!?!?!?!?!?!?!?!?!?!
ЗЫ сразу предупреждаю, что б лишний раз не напрягало, что я не имею в виду множественное наследование...
№ 2940 22-02-2007 04:03 | |
Ответ на »сообщение 2939« (Jean)
___________________________
"Магистрально-модульное программирование" (ММП)
Шино-монтаж или Модубас. :)
№ 2939 22-02-2007 03:43 | |
>>>Щас подумаю и выдам!
А чего думать.
Bus - это "шина", "магистраль".
Module - это "модуль"
Значит...
"Магистрально-модульное программирование" (ММП)
ММП vs. ООП
№ 2938 22-02-2007 02:31 | |
Ещё короче:
>>> ООП - инструмент ... трудно объяснять его необходимость ...
Здесь не только "currently fashionable".
Jack хорошо сказал: "за базовые классы опытного специалиста",
"за расширения - команду джуниоров". В результате и спец не всё делает
(есть резон отнять у него "вот стока денег") и джуниоры сыты и "серьёзная
команда" в наличии и без менеджера с его штучками никуда не деться.
То есть ООП широко распространён как удачный менеджерский приём
для проекта "деньги-софт-деньги", а сейчас эпоха или царство менеджеров.
Хотя структуре проекта в техническом и логическом смысле он, на мой взгляд,
только вредит искусственной топологией связей.
Не даром Руслан Богатырёв проговорился:
..." понимание видов объектов (классов) и их отношений (наследование)".
То есть организация связей по умолчанию в дерево. А ещё мне пеняли,
что я не понимаю разницы между иерархией классов и иерархией объектов
модели и что это разные вещи!
>>> Между классами устанавливалась зависимость, которую довольно
>>> неверно назвали иерархией наследования. На практике (с учетом
>>> связей типа has-a, uses-a, is-a) это не дерево, а граф.
Э, нет! "Померла так померла!" :) Это Вы слишком ловко!
Горизонтальные связи вводятся вопреки парадигме наследования.
Это вынужденное и кривое отступление, диктуемое сущностью решаемой
динамической, меняющей акценты и растущей с годами задачи.
Всё-таки это дерево с подпорками, подвязками, привоями и заплатками.
Назвать это графом - завуалировать имеющиеся серьёзные недостатки.
Почему бы не пристрелить эту загнанную лошадь ООП?
Ну, или менее кровожадно - на заслуженный отдых - травку щипать.
Так вот вопрос - если ООП в Обероне не дань моде и мейнстриму, то
почему же не всё на Generic Message Handler и "мягком автобусе" :) ?
Тут нужен хороший термин (слоган нужен, как ООП).
Щас подумаю и выдам!
№ 2937 21-02-2007 16:00 | |
Ответ на »сообщение 2934« (Geniepro)
___________________________
А материалы по Вашему курсу где-нибудь доступны вне МГУ? ...
Где-нибудь, кому-нибудь... да.
Было бы любопытно сравнить...
Вот специально для Вас самая средняя (по номерам) лекция осеннего семестра:
http://www.inr.ac.ru/~info21/08.pdf
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|