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

Всмысле, "вью запрашивает"? То есть, Вью о чем-то думает и потом такая "а что там у нас с доступными действиями?" :)
Вью не может о таком размышлять, Вью только реагирует на действия пользователя и события от Модели.
Ну и да, методы она не запускает, ибо ничего не должна о них знать; только через Контроллер.
Кто запускает цепочку событий, приводящую к необходимости Вью получить этот список?

Ведь Вью может обращаться к Модели за данными? Может. Вполне нормальная ситуация, когда Модель говорит: "Список доступных для игрока действий в студию!", а Вью по этому событию и запрашивает. Вот я и сделал сначала просто геттер, а потом он как-то постепенно перерос в серьёзный такой метод. Как принято говорить в подобных случаях, так получилось. :rolleyes:

Ответ по существу понял, как переделывать тоже уже понятно. Делаю переменную в модели, все результаты складываю в неё, а Вью оставляю возможность просто получить её содержимое.

Ещё мелкий вопрос по MVC возник. У меня в текстовом квесте формат выводимого пользователю текста (цвет, в первую очередь) может отличаться в зависимости от того, о ком идёт речь: герой, противник, повествование и т.п. ID каждой фразы генерирует Модель в зависимости от контекста, она же "знает", о ком идёт речь. Сейчас я сделал строковые ID форматов, которые хранятся в константах Модели и передаются вместе с ID фраз во Вью. Сами форматы - экземпляры TextFormat живут в форме публичных констант в отдельном классе пакета gui. Вью, получив массив инструкций от Модели, смотрит ID-шники формата в каждой инструкции, по нему подбирает нужный экземпляр TextFormat и засылает в область вывода - своему дочернему компоненту.

Вопрос. Не перемудрил ли я опять с системой задания форматов через строковые идентификаторы? Я исходил из принципа независимости Модели от конкретных способов вывода. Что типа сегодня это будут TextFormat-ы, а завтра - голограммы. Поэтому в Модели будут использоваться строковые ID, а как их обрабатывать - пусть Вью решает. Ведь можно дать Модели ссылку на TextFormat-ы и напрямую их выбирать и отправлять во Вью...

Звучит хорошо. Если только эти строковые идентификаторы достаточно абстрактны, а не являются обязательными к исполнению жесткими указателями именно на текстформаты. Ну, в смысле, хорошо если это просто указатель на то, кому принадлежит данный текст (то есть, КТО?) а не на то, каким цветом его красить (т.е. КАК?). Хотелось бы, чтобы собственно формат и прочее оформление выбирала Вью (или голос синтезатора речи, или открывающую рот 3D-голову))))

Спасибо, Wolsh. По всей видимости, я в данном вопросе мыслю в правильном направлении. Пока правда имею в распоряжении только текстформаты есть как способ дифференциации, но теоретически может быть всё что угодно, для этого и заморачивался.

По поводу оформления текста можно еще копнуть не в текстформат, а в CSS. То есть тексты сразу разметить как HTML, а форматирование хранить в классах CSS.

Модель содержит в себе всю деловую (предметную, buisness, domestic) логику и данные для оперирования с ее помощью. Модель сообщает её слушателям обо всех изменениях, произошедших в ней. Модель — это мозг приложения. Она очень развита и сложна. Сложнее неё ничего нет. Она есть основание, фундамент твоего приложения.

Ниже приведен пример неправильной трактовки модели. По мере возможностей избегайте такого. Это неправильная модель в MVC.
Для примера... В простом, казалось бы, кликере Evolution: Heroes of Utopia из двух месяцев моего участия в проекте, я потратил две недели на разработку модели. В этой модели есть самые главные забавные паттерны GoF: Composite, Prototype, Observer (EventDispatcher). Если декомпильнуть приложение (но помните, что на нашем форуме запрещено обсуждать декомпилированные приложения), то можно увидеть насколько сложна модель. Вьюхи я тоже писал, но там все проще. Для UI вьюх я воспользовался своим ранее написанным движком MXML powered by improved мною Starling. И вьюхи щелкались как семечки. Все остальные вьюхи и анимацию предоставляли художники и там все просто, как конечный FSM, которому нужно только слушать модель.

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

Так вот... Я потратил около двух рабочих дней на портирование моих наработок со флеша: мой любимый самописный EventDispatcher и ещё некоторое количество абстрактных классов модели. Да-да, composite рулит везде. Кстати, еще полдня ушло на то, чтобы понять, что "их" GC безжалостен к enum и delegate. Но это выяснилось уже на стресс-тестах с профайлером. В итоге, за четыре дня я написал модель, которая контролирует бои и все объекты в этих боях. Оставалось дело за вьюхами (collider у unity) и контроллерами. Но это другая счастливая история.

Вот так, малята. Если начинаешь MVC, то не забудь, что MVC начало тебя. Но это того стоит. Скорость разработки просто зашкаливает.

Советую затестить с включеным виндовым увеличением:
Вложение 33205

Спс. Я не участвую в этом проекте чуть меньше двух лет. И того флэшера, который его поддерживал, уволили практически в то же время.