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

NotGonnaGetUsОпять же, каков процент "студентов" среди общего числа разработчиков и какие "куски проектирования" им можно давать? :)
Это непростой вопрос. У многих "студентов" присутствует неподтвержденно высокое мнение о своих возможностях, соответственно желание взять большой кусок задачи...... некоторые таки его неплохо делают :)

Я бы сказал - в первую очередь давать "не очень важный кусок". Большой, если нужно, но такой, чтобы из-за его отсутствия или необходимости переделки не пострадали другие задачи.

Ну а дальше - вопрос не столько в том, "какие куски давать", сколько "насколько плотно и тщательно при этом контролировать".

NotGonnaGetUsПредлагаю так же, не делать тождества между "наследованием" и "проектированием".
Безусловно, не следует. Я в данном случае употребил проектирование исключительно как стадию, в ходе которой возникает желание отнаследовать.

NotGonnaGetUsТ.е. с оценкой 90% на 10% вы категорически не согласны? :)
Я полагаю, что дисперсия этой оценки делает ее бессмысленной. Грубо говоря, есть люди, у которых будет 100/0, а есть люди, у которых будет 60/40. Для одних и тех же задач.

NotGonnaGetUsПримем в первом приближении, что глядя на задачу можно объективно оценить к какому из двух классов она принадлежит
Именно это приближение я не готов принять. Точнее, я безусловно способен "объективно оценить" со своей колокольни, но абсолютно уверен в том, что при статистически значимой выборке оценивающих мы получим прорву других объективных оценок. При этом поставить эксперимент "чьи оценки в итоге окажутся точнее" весьма затруднительно.

Мало того, я полагаю, что тут есть определенная вариативность, и там, где для себя я выбрал бы вариант А, другому человеку я сам бы сказал: знаешь.... делай лучше Б.

NotGonnaGetUsМоё имхо, что отношение получится 90/10, из чего я делаю вывод, что среди людей обсуждающих наследование, и в особенности МН, преобладают люди не имевшие возможности на практике проверить истинность своих теорий.
Я существенно более оптимистичен. По нескольким причинам, из которых в первую очередь назову следующую: даже того, что Вы отнесли к 90%, на самом деле хватает, чтобы сделать многие верные выводы. Не обязательно учиться на собственных ошибках.

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

TimmНадо б вначале научить людей мыслить в терминах ООП... без МН. а не кодить процедурно.
Для начала хорошо бы понимать, что ООП - это синтаксис, ничего нового в мышление оно не вносит. Ровно как break - удобный синтаксис записи частного случая goto, так и допустим виртуальный метод - удобный синтаксис записи частного случая указателя на функцию. Человек либо умеет выбирать адекватное решение - и выбирает его безотносительно ООП - либо не умеет, и получаем -

Timmгрязно плююсь от текущего колупания в лапше из if'ов и switch'ей
Именно что. Лапшу можно делать из ASSIGNABLE GOTO (была такая прелестная форма этого оператора), можно из ифоф и свитчей (я как-то на спор написал фрагмент программного кода в стиле "классическое спагетти", пользуюясь только и исключительно "структурными" if и while), ну а последние лет десять я периодически ругаюсь словами "объектно-ориентированное спагетти".

TimmСинтаксис - это язык, в терминах которого человек выражает объедко-ориентированные мысли. о как :)
Как называть эти мысли - вопрос имхо десятый. Мне трудно называть "объектно-ориентированными" мысли, которые появились и были известны в семидесятых годах. Главное - понимать то, что есть мысли [сами по себе], есть форма их записи на конкретном языке. К сожалению, большинство авторов книг смешивает эти понятия, создавая разруху в головах.

LeonidvС другой стороны, я все-таки думаю, что думать на ООП можно. Тут получается другой стиль мышления, чем при линейном (так оно называется?) программирование.
Нет. Линейное программирование - это ну совсем другая тема, к "программированию в нашем смысле" относящаяся опосредованно: http://www.dvo.ru/studio/linpro/lp1st/node3.html

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

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

Leonidv(Я практически сразу стал писать с помощью объектов. Кстати, писал на Дельфи, а про объекты узнал из книги на Java. И еще потом лет 6 писал(пишу) на Дельфи).
Увы, классическая история из серии "учил дельфу по плохой книге".

Мне в этом плане повезло, поскольку про объекты я узнал лет за восемь до появления явы.

LeonidvНу а на счет программистов, которые используют проектирование или нет. Кому что в жизни надо, тот это от жизни и берет. Вряд ли системному программисту, которые пишет встроенное ПО нужно ООП. Они вообще стараются на C писать
Хм. Подумайте еще раз: если ООП - это способ мышления, какая разница, на чем писать? Те идеи, которые ассимилировало ООП, как раз и привели к появлению Паскаля, Си, Ады; собственно, ООП по большому счету выросло из обобщения опыта работы на этих языках. Эти идеи отлично реализуются на ассемблере, на любом интерпретаторе, сугубые проблемы будут лишь на старых компиляторах типа Fortran IV или PL/I.

То, что Вы говорите, как раз служит иллюстрацией к "путанице между идеями и синтаксисом", о которой я говорил чуть раньше.

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