Без скинов нету профита.
Проще в пару классов всё всунуть. Одна модель на всё приложение и какое-то дерево вьюх на пару уровней.
Не уверен что контроллер нужен даже.
А со скинами - при наличии медиатора одни и те же пятнашки могут старлингом рисовать с партиклами в 3д, а могут шейпами и псевдографикой.
Опять же и без медиатора можно, но тогда как минимум с ивентами будет попа в том же старлинге. Из старлинговских пятнашек в контроллер ниче не продиспатчишь нормально, или же придется тупо всё на старлинг перепиливать.
При наличии медиатора - медиатор может реализовывать интерфейсы стандартных флешовых ивентов и для старлинга содержать небольшую оберточку для конвертации.
Медиатор сможет понимать и старлинг кубики с партиклами и шейповые анимации на дефолтном ДЛ.

Эту абстракцию можно и прямо в контроллер вынести, но тогда он станет большим и толстым. С медиатором изящнее.

Есть и другие варианты реализации этой задачи, но раз уж речь о медиаторах ;)

Спасибо всем за объяснения.
Вот как я понял [паттерн] медиатор, когда читал GoF:
"Медиатор это бригадир контроллеров")))
Решающий, например, такие задачи как замена одного контроллера на другой (ну а кто решит такую задачу? не Модель же будет "менять" контроллеры, правда? Она и о текущем то ничего не знает, тем более о Вью, которую контроллер контролирует. Может, Вью будет решать? Вью — решать? Ну а Контроллер, который я мыслю только тонким, тот вообще не в курсе что происходит). То есть вот например поменялось у игры состояние, открыли меню Паузы, или даже окно Инвентаря. И всякие там клики и движенья мышкой по экрану имеют совершенно другой смысл, нежели в процессе боя. Строго говоря, мы активировали другую вьюшку и она через свой контроллер фигачит свои особенные события в свою особенную модель. А "пацаны то не знают!". Представим на секунду, что действия в Инвентаре должны так же влиять и на окно самой игры. Например, выпил герой элексирчика и порозовел. Поменял меч на щит. Надел защищающий от огня амулет и перестал гореть (в некоторых играх инвентарь не только позволяет видеть, что там в игре происходит, но иногда даже не останавливает время в игре (напр. STALKER). Теперь еще одно примечание — все эти же действия (выпить элексир, надеть амулет, взять щит и т.п.) могут инициироваться игроком и безо всякого окна инвентаря нажатиями на особые "быстрые" клавиши. То есть механизм вью-контроллер-модель для таких действий уже существует и БЕЗ контроллера окна инвентаря. Другими словами, уже есть [другой] контроллер, способный передавать в модель эти действия, но он не связан с вьюхой инвентаря. С другой стороны, съеденная нажатием "быстрой клавиши" во время боя аптечка должна сократить кол-во аптечек в инвентаре, а не только поправить здоровье. Так вот Медиатор в моем понимании это тот, кто может устанавливать подобную связь, дергая в контроллере "выпить эликсир" при действиях пользователя в РАЗНЫХ окнах (вьюхах). То есть ловить разные события от разных вьюх и, интерпретируя их как одинаковые, дергать соответствующие контроллеры И инвентаря, И боя, И чего-то там еще (HUDа, к примеру). Медиатор обеспечивает перекрестную подписку разных контроллеров на разные события, а так же управляет наборами таких подписок в зависимости от "состояний" приложения.
Это то, как понял я. Это не соответствует действительности?

Моей - нет.

Это MVP - когда контроллер запускает методы View. Учите матчасть

В моей действительности все контроллеры всегда активны, равно как и все модели.
Т.е. они всегда готовы принять команду от пользователя, все одновременно.
И вот есть допустим контроллер инвентаря. И модель инвентаря.
И есть контроллер куклы игрока, и модель куклы игрока.

Теперь как происходит распитие напитков вызывающих порозовение без учета вьюхи:
- Контроллер инвентаря дергает модель инвентаря.
- Модель инвентаря расходует эликсир. И каким-то чудом эта же информация попадает в модель куклы (мол мы эликсир не просто выкинули, а всё-таки выпили) (как именно эта информация туда попадает - тонкости реализации. Я видел реализации с бабблингом по моделям, видел с обсервером, тут уже ваша смекалка и тонкости задачи включаются)
- обе вьюхи видят изменения в своих мделях. Инвентарь показывает на единичку меньше, а кукла розовеет.

//**********************

Теперь добавим сюда вью.

КАКИМ образом запустится этот процесс?
У нас есть хоткей - это вроде как тоже вью, но абстрактная.
Есть окно инвентаря.
Есть еще куча мест в которых мы можем спровоцировать этот клик и дальнешую цепочку.

//*******************

Т.е. это второй вопрос такой же как и "как данные между моделями синхронизируются".
Реализаций море, и ни одна из них не завязана на медиаторах.
Опять же видел бабблинг по вьюхам. Кликнули в панели, а все контроллеры которым надо - получили ивент.
Видел обсервер более топорный (у самого такой).
Видел когда в контроллер инвентаря тупо инжектятся все вью которые могут запустить процесс изменения инвентаря.

//***********************

Т.е. тут вопроса о медиаторе никакого.

//***********************

Медиатор это допустим открыли мы окно инвентаря.
а в окне инвентаря мы можем покупать хоткеями, а можем покупать кликами.
Это по сути две вьюхи - абстракная для хоткеев и визуальная для кликов.
Но контроллеру пофигу. Эти две вьюхи для него выглядят как одна вьюха окна инвентаря. А медиатор уже обе из них слушает. И выдает контроллеру инвентаря универсальное апи работы с инвентарем.

Добавлено через 4 минуты
"В результате такого понимания MVC разработчики стали писать код, который Pádraic Brady, известный в кругах сообщества Zend Framework, охарактеризовал как ТТУК — «Толстые тупые уродливые контроллеры» (Fat Stupid Ugly Controllers)[6]:"
Пруф
Раздел: "наиболее частые ошибки".

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

Окей же шь?

Добавлено через 20 минут
(я на Вашей совести пока оставлю всякие баблинги между моделями и т.п., не готов сейчас всерьез это обсуждать — мне больше по душе слоистость MVC-структур в проекте, а не одна большая Куча перемешанных моделей, каждая из которых обязана заботиться о других, выступая для них контроллером. Пусть там, где у меня написано контроллерЫ, будет один очень многоплановый контроллер, знающий сразу все модели или их общий фасад МатьВсехМоделей, но не знающий вьюх, замененных Медиатором).

Добавлено через 24 минуты
Смысл, короче, был в том, что контроллерам не надо знать "чужих" вьюх и "чужих" моделей. Координацией занимается Медиатор, а каждый "модуль" остается независимым и самодостаточным == реюзабельным.

Да шо вы говорите! Совершенно не важно толстый или нет контроллер - сути не меняет, это паттерн MVP. Плохой он или хороший зависит от конкретной ситуации. Плохого в толстых контролах , как я уже сто раз говорил, нет. - все зависит от задачи. При 1-2 контроллах в приложении можно использовать вообще связку - вызов методов контролом главного вида, а так же и слушанье модели видом - каша да получится? То то, то другое?! Только даже в этом случае назвать это *****-кодом не получится, дабы приложение будет работать пускай и по смешанным стандартам, но вполне себе, и к тому же - легко модифицируемо, даже с такой кашей. Но я конечно против каш, лучше либо одно использовать, либо другое.
А *****код это писать так
Почему *****код?
а) в таком коде невозможно разобраться и понять что есть что
б) название переменных и функций должно быть логичным
в) i - как итератор предназначен для счетчика цикла и использовать его в других случаях не по феншую
г) Если метод ничего не возвращает - это тип void
И т.п.
Я знаю одного пхпшника, который кодит уже 20 лет, сотни проектов, тысячи клиентов и т.п. - не важно. Так вот он пишет именно такой код для любых языков которые использует, любой метод у него обозначен 1-2 буквами, переменные и того не более. Вот он пишет реальный *****-код, однако стать ценным сотрудником для многих он смог, программы его работают и про утечки памяти никто не слыхивал. А вы тут обсуждаете какую то фигню, считая адекватный паттерн МВП - *****кодом. ну смешно же

С моей колокольни если г-нокод инкапсулирован в пяти строках в одном классе это и не г-нокод вовсе.
Его рефакторить это 10 минут делов.
А плохой код это когда у вас вью начинает считать логику, а контроллер подписывается на модель.
Такое г**нище распутывать запаришься. И я вас разочарую - вот такое вот обычно написано красиво. С первого взгляда в нем даже г-нокод идентифицировать сложно.

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

Добавлено через 1 минуту
Ну на каком-то уровне абстракции наверное так и есть.
Я более уточненно и приземленно эту ситуацию рассматривал.

Добавлено через 2 минуты
Я примерно с такой же точки зрения смотрю сейчас.

Добавлено через 4 минуты
дабы == чтобы
ибо == потому что

Ну так я Вашу и написал)
Это как бы не самая суть дела, чем там занимаются модели друг с другом, медиатор то в их спальню не заходит. Смысл в том, что "HUD" это Вью HUDa, Контроллер HUDa и Модель HUDa. И медиатор позволяет этому так и оставаться, независимой от всего остального триадой.
Да, Ваше упрощение помогло мне лучше увидеть, более цельно. Спасибо))

Ну я рад что помог:)