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

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

Именно поэтому "применение паттернов" порождает так много проблем сугубо номинативного порядка: этот термин подразумевает слишком много, чтобы обозначаемую им сущность можно было именно применять. И относительно слишком многих вещей не понятно, на сколько они обязательны. Прежде всего, подразумевается ли здесь определённая реализация, или нет? Если да — то какая именно, если нет — то... Дальше мысль останавливается.

A>Два бенефита, которые от этого можно получить:
A>1. Можно сказать короткое "у нас там Observer" вместо длинного "у нас есть A и B, при этом в A происходят всякие события, а B слушает эти события".

Да, но только если обе стороны знают, что есть A, B и события. Если же это не известно, то вторая формулировка предпочтительней.

A>2. "Если есть привычка" — можно глядя на десяток компонентов решения определить как они связаны друг с другом: снова вместо "A что-то там делегирует B" — увидеть "A и B взаимодействуют как Observer и Observable, т.е. оформлены в виде паттерна Observer".

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

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

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