[Panzermaus]

x-yuri, с MVC пришли к консенсусу Даже по вопросу M/V/C vs. M/VC, что вдвойне приятно. Это на серверной стороне отдельные V/С уместны, так как там input и output естественным образом разделяются.

Кстати, твой глобальный контроллер... я бы его все-таки каким-нибудь координатором/диспетчером назвал

Согласен, надо назвать этот паттерн Model-View-Dispatcher aka MVD

ну это по сути мой второй вариант.

Разница есть. Это не list2 = new List({'linked-with': list1}), а скорее list2evt = new List({'filter-when': 'event1'}). Кто является источником event1, сколько тех источников (и есть ли они) для list2evt все равно.

А по поводу событий, это по определению более сложный вариант взаимодействия.

Да, это цена за определенные преимущества, которая может быть как чрезмерной, так и вполне приемлемой, в зависимости от ситуации.

Когда мы видим вызов метода, мы знаем, что объект-назначение один, в случае события это уже не очевидно.

Снова-таки в зависимости от конкретной ситуации, это может быть и недостатком, и достоинством. Пример: получателями события CountryChanged могут быть не только cityList, но и imgFlag, yourRegionalDealerContacts, да и мало ли что еще.

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

А вот это чегтовски серьезное возражение! Поскольку ни одного законченного event-driven фреймфорка я не написал, то со скользкими случаями мог попросту не сталкиваться. Правда есть подозрение, что в действительно сложном случае взаимодействие через интерфейсы тоже хлебнет горя Пример бы...

В результате мы повысили реюзабельность за счет более сложного взаимодействия и большего количества компонентов (список/зависимый список), либо просто усложнили взаимодействие

В случае двух списков так и выходит: было 2 компонента и 1 зависимость, стало 3 компонента (+диспетчер) и 2 зависимости. Но допустим, взаимодействующих компонентов 10. Между ними может быть от 9 до 90 зависимостей - это и есть "конкретная ситуация". И это еще не все: зависимости могут быть очень разнообразны, например, если компоненты A, B, C зависят от X, и X потребовалось заменить на Y с другим интерфейсом, то A, B, C нужно будет подвергнуть переделке неизвестно какой глубины - от названий методов до всей логики.

А при взаимодействии через события количество компонентов хотя и увеличивается до 11, но зависимостей будет строго 10, причем зависимости исключительно однообразны и просты (подразумевается, что интерфейс диспетчера стабилен.)