А что он поймет в чужих решениях без теории? Вы в институте учились? Сомневаюсь, что вы сначала практические задания делали, а потом только лекции по сделанному читали.
Не согласен. Проектирование - вполне определенный процесс с определенными целями - уменьшить стоимость владения продуктом. При неизменности условий задачи и опыте проектировщика именно выбранные в процессе проектирования решения дадут заданный результат. Ну а если приземлиться на землю и думать о проектировании только в терминах "какой паттерн проектирования выбрать", то в общем тоже не верное утверждение. Паттерн проектирования - это, говоря языком "кодирования", общеизвестная общедоступная и общераспространенная функция(класс, библиотека). Как применение такой библиотеки в кодировании облегчит написание и понимание кода по сравнению со своей реализацией такого же функционала, так и паттерн проектирования где-то уменьшает время на придумание своего велосипеда и облегчает понимание кода в дальнейшем. Т.е. использование паттерна однозначно выплоняет ту задачу, которую на паттерны возложили - переносимость между головами разработчиков. Да, конечно, использование патернов не значит, что потом не потребуется рефакторинг потому-что где-то что-то недостаточно гибко и где-то что-то не предусмотрели. Но во-первых, универсальной гибкости просто не бывает, так что это вообще не достижимо. А во-вторых, я с этого и начал, проектирование несколько более глобальный вопрос, чем просто решить, что мы используем MVC, а общедоступные объекты будем гонять через абстрактную фабрику.
Но в общем это рассуждения о кактусах, и практической пользы не несет, так что лучше пойдемте создавать добавленную стоимость, чем философствовать.