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

Ну не можете обосновать, значит, не можете.

А разве спрашивать не нужно "мочь"?

Ответ на »сообщение 4662« (Как слышно? Приём!)
___________________________
>>>Видимо, класс задач, который Вы решаете, допускает чёткое очерчивание
с последующим отлитием в бронзе модели и программного кода.
Насчет бронзы не понял - хорошая иерархия позволяет очень разнообразное развитие.
Но предметная область должна быть определена. И проблемная область должна быть определена. Иначе никаким методом не построить приличную программу. Ни ООП вообще, ни наследование в частности тут не при чем.
>>>Для эксплуатационщиков задача в поддержании инженерной системы
ритмично 5-го и 20-го :) с изменением условий и даже самой модели.
А примерчик можно? А то меня все пугают изменением требований, а мне как то не страшно. Вот ни разу мне не пришлось всерьез перекраивать дерево наследования при развитии системы. А некоторые проработали по десять лет. И VCL приходилось писать на Паскале, и с базами данных работать и с базами знаний. Обработку звука делали и с изображениями работали. Статистикой, естественно, баловались. И все как то хрупкость классификации не сказывалась.
Может не в ООП дело, а в консерватории подправить что-то надо?

Ответ на »сообщение 4661« (Сергей Губанов)
___________________________

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

>>>Google это не подтверждает...

Он подтверждает широкую распространённость неграмотного использования термина (ведь там речь фактически идёт о мультиметодах).

Не тот ли это случай, когда только один "шагает в ногу"? ;)

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

По поводу различий в понимании ООП.

http://www.piter.com/lib/978588782270/oop.phtml?fil=oop_ch1#1.7

Многие авторы пытались дать строгое определение тех свойств языка программирования, которыми он должен обладать, чтобы называться объектно-ориентированным, — см., к примеру, анализ, проведенный Джозефиной Микалеф [Micallef 1988] или Питером Вегнером [Wegner 1986].

Вегнер, к примеру, различает языки, основанные на объектах, которые поддерживают только абстрагирование (такие, как Ada), и объектно-ориентированные языки, которые поддерживают наследование.

Другие авторы — среди них наиболее заметен Брэд Кокс [Cox 1990] — определяют термин ООП значительно шире. Согласно Коксу объектно-ориентированное программирование представляет собой метод или цель (objective) программирования путем сборки приложений из уже имеющихся компонент, а не конкретную технологию, которую мы можем использовать, чтобы достичь этой цели. Вместо выпячивания различий между подходами мы должны объединить воедино любые средства, которые оказываются многообещающими на пути к новой Индустриальной Революции в программировании. Книга Кокса по ООП [Cox 1986], хотя и написана на заре развития объектно-ориентированного программирования, и в силу этого отчасти устаревшая в отношении деталей, тем не менее является одним из наиболее читаемых манифестов объектно-ориентированного движения.

1)
>>> #4548 (С. Перовский)
>>> Отличие модели в том, что рано или поздно объект из рассмотрения должен быть исключен,
>>> иначе она будет разрастаться до исчерпания ресурсов
>>> #4590 (AVC)
>>> ООП есть способ манипулировать объектами, чей окончательный тип заранее неизвестен.

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

>>> #4591 (С. Перовский)
>>> Построение эффективной классификации на основании наиболее значимых признаков
>>> дает мощную базу для ООП.
Правильно. Удел ООП - модели на основе статической классификации.
Видимо, класс задач, который Вы решаете, допускает чёткое очерчивание
с последующим отлитием в бронзе модели и программного кода. Fire & forget.
Для эксплуатационщиков задача в поддержании инженерной системы
ритмично 5-го и 20-го :) с изменением условий и даже самой модели.
Вроде как речь о динамическом программировании и загрузке модулей,
организации их связей и сопутствующей требухи?
А вот разговор от ООП:
.    Хотите статику - полезайте на дерево наследования,
.    хотите динамику -... всё равно на дерево. Что? Не влезает модель?
Поднажмите полиморфизмом, да не сильно, а то дерево хрупкое ...

2)
>>> КП предлагает построение инструментов, а не сам есть инструмент.
А что? Это почти слоган. Вот это можно пожевать. Это тоже ниша.

3)
Давеча в Перми таки присудили 5000 за незаконный софт в преподавании.
Надо использовать случай для борьбы с возмутительно недопустимым
контрафактным использованием продукции M$ в наших школах.

4)
Профессионалы в запарке бессонными ночами, с соблюдением стандартов
и правил коллективной разработки выдают софт для чипа. Потом его оптимизируют
тестируют и сдают, а потом выстреливают в южную часть Тихого океана, где он тонет
вместе с документацией за грифом "совершенно секретно". Цикл повторяется.

А нормальные инженеры решают свои задачи на софте для других целей - для работы.
На удобном, интерактивном, простом для понимания, который не ставит себе целью
"отшивать "случайных прохожих" уже на ранней стадии". Тоже мне критерий!

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

Ответ на »сообщение 4647« (Сергей Губанов)
___________________________

В своём сообщении я лишь сообщил, что рускоязычный перевод "двойная диспетчеризация" давным давно забит за пунктом (1)

Google это не подтверждает...

Он подтверждает широкую распространённость неграмотного использования термина (ведь там речь фактически идёт о мультиметодах).

Ответ на »сообщение 4658« (Владимир Лось)
___________________________

Скажете - тупо? А - нифига! Это - НОРМАЛЬНО с ИХ точки зрения.
Ещё раз повторюсь: для себя вы можете писать на чём угодно, но вас не поймут если код будет отчуждаемый или на заказ на сопровождение.

Собственно, все хорошо: код на Си++ будет, как всегда, прост, надежен, отчуждаем и сопровождаем.
- НОРМАЛЬНО, Григорий?
- ОТЛИЧНО, Константин!

Ответ на »сообщение 4658« (Владимир Лось)
___________________________

Ответ на »сообщение 4657« (AVC)
___________________________
Но я уловил такую мысль: Оберон не соответствует куче стандартов и внутрикорпоративных соглашений.
Правильно?
Это - только одна из причин. Хотя, для менеджирафф - чуть ли не основная. Им людей нанимать.
Да понятно это все...
Но ведь в индустри все равно есть и будут эксклюзивные проекты, под которые людей набирают "не с улицы". Под такие проекты можно и инструменты "не с улицы" набирать, особенно если для специалиста дело освоения такого инструмента - пара недель...
Были же в России примеры, когда в качестве языка для отв. проекта выбиралась та же Ada - и когда никто из будущей команды ее не знал (бортовое ПО Бе-200, кажется). И потом с гордостью говорили, что освоить язык оказалось делом 2 недель, зато какая отдача...
Так КП - не Ada... :-)

Ответ на »сообщение 4657« (AVC)
___________________________
Но я уловил такую мысль: Оберон не соответствует куче стандартов и внутрикорпоративных соглашений.
Правильно?
Это - только одна из причин. Хотя, для менеджирафф - чуть ли не основная. Им людей нанимать. На второй работе, когда я завёл разговор про КП, мой тим-лидер набрал в поисковике Component Pascal и С++ и по соотношению количества ссылок продемонстрировал успешность поиска программистов на проект на КП...
Скажете - тупо? А - нифига! Это - НОРМАЛЬНО с ИХ точки зрения.
Ещё раз повторюсь: для себя вы можете писать на чём угодно, но вас не поймут если код будет отчуждаемый или на заказ на сопровождение.

Ответ на »сообщение 4652« (Владимир Лось)
___________________________

Ответ на »сообщение 4650« (AVC)
___________________________
Дело в количестве библиотек?
Ну давайте я скажу - да. И что? А какой-нить человек (например из Зеленограда), не связанный тем количеством и напряжённостью связей и обязательств, как, например, я, скажет - "а - нифига! - мне всего хватает". Да, он сидит себе и, в режиме "не бей лежачего", нарабатывает набор тулзовин и модулей ДЛЯ СЕБЯ или - "ближайшего "окружения".
На промышленный уровень он выходит? С подтверждением кучи стандартов и внутри корпоративных соглашений? В его случае он не находится под "катком" сроков и стандартов. Сможет он своим набором утилит "каток" развернуть?

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