Здравствуйте, Ikemefula, Вы писали:

I>На мой взгляд, между паттернами и дизайном вообще нет ничего общего.

Совершенно не соглашусь со всем написанным. Очень часто сам феномен "паттернов" интерпретируют совершенно неверно: утверждают, что паттерн — это шаблон куска кода, в который нужно подставить специфику конкретной задачи и получится готовое решение. На самом деле паттерны в первую очередь описывают структуру взаимодействия нескольких компонентов и по большому счёту просто дают название для этой структуры. Мне тут полгода назад с пеной изо рта доказывали, что "в C# не нужен паттерн Observer, потому что в C# есть механизм событий" — это очень хороший пример непонимания происходящего. Паттерн Observer в одном из частных случаев описывает 2 участников, таких что:
1. В первом происходят какие-то события и он позволяет желающим на них подписаться
2. Второй хочет знать об этих событиях и, соответственно, умеет их слушать
Всё — тут ставится жирная точка. Если у вас во время "дизайна" решения возникла похожая ситуация, можно смело называть это словом "паттерн проектирования Observer". Независимо от того как вы это всё запрограммируете.
1. Будете ли вы использовать какой-то стандартный IObservable со своей реализацией
2. Будете ли вы использовать какую-то стандартную реализацию типа AbstractObservable
3. Будете ли вы писать полностью свою реализацию MyVeryBestAbstractObservable
4. Будете ли вы использовать какой-то event bus
5. Будете ли вы использовать какой-то специфический механизм языка — те же events в C#
6. Напишете ли вы под эту задачу свой собственный самый лучший ЯП с парадигмой observable-oriented programming
это всё совершенно один и тот же хрен — "паттерн Observer". Два бенефита, которые от этого можно получить:
1. Можно сказать короткое "у нас там Observer" вместо длинного "у нас есть A и B, при этом в A происходят всякие события, а B слушает эти события".
2. "Если есть привычка" — можно глядя на десяток компонентов решения определить как они связаны друг с другом: снова вместо "A что-то там делегирует B" — увидеть "A и B взаимодействуют как Observer и Observable, т.е. оформлены в виде паттерна Observer".

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