Что касается правильного фреймворка: поживём — будем посмотреть.

А быстрое и правильное обучение разработчиков – это отдельный вопрос, мы его уже обсуждали… Поддерживать сайты на LSF увы надо, вопрос в том, чтобы не писать legacy код прямо сейчас . С платформой вообще сложности, так что правильный фреймворк безусловно нужен.

Юра, не в обиду: где-то я такое уже видел. Я имею в виду swiss knives в коде, а не фразу, разумеется.

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

Это понятно. Проблем тут пресс. И ключевой является мотивация. Если ты постоянно демонстрируешь реальные преимущества OOP/OOD — то люди будут учиться. Если нет, то… Вообще, когда я интенсивно общался со сверстниками, то была мода на «Совершенный код», а вот к «Паттернам проектирования» люди были равнодушны (ну, или около того). Вот как ты замотивируешь сотрудника на изучение принципов ООП(рограммирования) и паттернов ООП(роектирования), если ему надо поддерживать сайты на LSF?

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

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

А связка с образованием (по итогам jabber переписки) – у нас учат «писать» ОО-код, но не учат думать в ОО-парадигме, т.е. не учат ОО-проектированию. Это, как если бы учили как записывается цикл, что он перебирает числа от 0 до N, но не показали бы, что циклом можно решать алгоритмы, ходить по матрицам, спискам, вычислять что-то и т.п.

Про наследование сказано мало, поэтому мы, издавна привыкшие читать между строк, решим, что совпадаем в понимании (что наследование есть средство описания нового класса на основе уже существующего (родительского), с заимствованием свойств и функциональности у родительского класса), и остановимся только на одной фразе: «Особенно прикольны рассуждения “этот метод нужен в 3 из 5 наследников, давайте поднимем его в родителя”».
А что смешного? Если этот метод нужен в трёх из пяти наследников, то на этом куске иерархии классов стоит остановиться подробнее в любом случае. Возможно, мы поднимем его в родителя, возможно, введём в иерархию родительский класс для этих трёх из пяти наследников, возможно вообще хорошо подумаем головой и перепишем нафиг этот кусок иерархии.

Полиморфизм. Тут да. Его надо рассматривать «на базе интерфейсов». Полноте, а разве мы не рассматривали на базе интерфейсов (спецификаций) инкапсуляцию и наследование? Можно быть ещё смелее, и сказать, что полиморфизм есть множественная реализация одного и того же интерфейса.

Подытожим то, что я имею сказать не по бумажке.
Имхо, начиная мыслить в категориях ООП, нужно в первую очередь перейти на понимание различия понятий спецификации (интерфейса) и реализации. Это и есть тот самый «сдвиг парадигмы» (‟paradigm shift”), который нам обещали при переходе от концепции процедурного программирования к концепции ОО.