Хорошее MVC

[Dukobpa3]

Ну координаты объекта ведь поменялись, значит очевидно же что надо отсортировать.
Следовательно мы организовываем вьюху таким образом чтобы каждый раз, как меняются координаты объекта всё что нужно - сортировалось. И контроллер тут ни при чем, равно как и модель.

[Zebestov]

Значит в модели нечего менять

В модели изменятся X и Y юнита. Кто даст команду на перемещение — контроллер или отображение — в данном случае несущественно. Я бы делал это из контроллера.

Контроллеру тоже до фонаря - его интересуют лишь x, y и пр. свойства

Контроллеру неинтересны эти свойства, если он не заведует логикой (которой хорошо бы быть в модели).

Значит надо передать вьюхе что нужно отсортировать экранные обьекты

Отображение само узнает о необходимости перерисовки, когда модель сообщит, что юнит переместился.

[Dukobpa3]

Но если модель будет и хранить данные и обрабатывать их - зачем тогда нужен вообще контролер? Просто чтобы быть ненужным посредником между моделью и вьюхой?

Ну если говорить о таком МВЦ как в вики пишут, типа правильном то это всё должно выглядеть примерно как в макдаке.

заказчик - вью
официант - контроллер
модель - кухня и прилавок

заказчик-вью подошел, заказал.
контроллер-официант правильно интерпретировал заказ (на входе может может быть что-то типа: "мне вот такую вот хрень, я у вас когда то был, но не помню как называется"), передал на кухню.
кухня приготовила, выставила результат на прилавок.
вью видит что на прилавке стоит ее поднос - идет забирает.

[HardCoder]

Представление:

Берет из модели массив юнитов. Размещает их в дисплейлист. Она не знает на какие координаты их размещает. Координаты уже заранее предписаны каждому юниту во время их создания в контроллере. Но! она знает на какие глубины их размещать. Не важно откуда знает. Знает и все. Это ее дело заниматься сортировкой (удобным отображением), потому что именно она вызывает addChild-ы а не кто-то другой из триады.

Контроллер:

Получает известие от вьюшки что пользователь выбрал юнита, кликнул на карту и надо этот юнит переместить на место, куда кликнул пользователь. Контроллер лезет в массив юнитов (в модели) вытаскивает оттуда нужного юнита и говорит ему: "двигайся туда". Юнит покорно, при каждом шаге высчитывая новые координаты, двигается. То что он перемещается знает только он сам и юзер, который видит на экране перемещение. Когда юнит пришел на место - он сообщает конролеру, что тот прибыл. Контроллер знает что раз тот прибыл - значит положение изменилось и надо пересортировать карту. Что делать?
Бежим к модели - та курит в сторонке - ей вообще по барабану. Она знает что юнит никуда не делся из ее массива. Переместился? ну и что? Координаты можно узнать от самого юнита.
Так кто же должен сообщить вьюхе, которая понятия не имеет что произошло - что юнитов надо отсортировать?

Добавлено через 3 минуты
PS: повешать слушатель во вьшке на юнита мы не можем. Это может сделать только контроллер. Потому что вьюшка передает контроллеру что был произведен клик, а тот уже определяет с помощью сотен строк что дальше с ним делать (перемещать, атаковать, умирать) и отдает ему команды. Представление заранее не может знать что конкретный юнит будет перемещен.

[Dukobpa3]

всё плохо

Модель: содержит набор абстрактных данных таких как координаты, имена и прочее. Без всяких визуальных объектов.
Представление: Содержит визуальную интерпретацию абстракций заложенных в модели. Например в модели у нас некий Object{type:type, x:x, y:y} - а вьюха уже знает что такой тип выглядит так, и находится по таким координатам.
Контроллер: получает от вью событие клика. Вносит в модель новые координаты объекта. На этом всё.
Вью: слышит маяк от модели что ее поменяли. Смотрит что поменяли координаты такого-то объекта, а текущие координаты то отличаются. И вот вью покорно начинает двигать объект с точки на точку с анимашками и прочими свистелками.

[fish_r]

Сообщение от Dukobpa3

Контроллер: получает от вью событие клика. Вносит в модель новые координаты объекта. На этом всё.
Вью: слышит маяк от модели что ее поменяли. Смотрит что поменяли координаты такого-то объекта, а текущие координаты то отличаются. И вот вью покорно начинает двигать объект с точки на точку с анимашками и прочими свистелками.

Модель не должны интересовать координаты объекта, для неё объект - некая статистическая единица, с набором соотв. информации (кол-во жизни, патронов и пр.), ИМХО, конечно (на классика пока не тяну )).
Думаю, что контроллер должен трансформировать данные из вью-типа в данные модель-типа, что собсно
и является его прямой обязанностью.

И так вопрос. Контроллер обработал некую информацию. В соответствии с этой информацией нужно провести изменения в представлении. Но дело в том, что эти изменения модели не касаются. Что делать? Напрашиваются такие варианты:

Если говорить не о "хорошем" MVC, а о классической реализации, то контроллер интерпретирует данные
и при необходимости изменяет вьюер (не знаю конкретики, но звено "контроллер", почти всегда лишнее, если события порождают информацию касающуюся только вьюера).

[HardCoder]

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

[Dukobpa3]

PS: повешать слушатель во вьшке на юнита мы не можем.

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

[HardCoder]

Короче говоря - надо все переписывать. Я как-бы понимаю что такое MVC, и понимаю что моя стратегия написания неправильна. Но в то же время не понимаю как мне полностью абстрагировать вьюшку от всего происходящего, как организовать работу их троих... Конечно, каждый случай уникальный, правила игры уникальные, поэтому мне самому нужно думать. Но может, если кто-то делал хотя бы похожее, подскажите, пожалуйста, как вы строили эту структуру.
PS: все делается без сервера.

[Dukobpa3]

Ну переписывать это кардинальное решение)
Как сделать я тебе уже ответил, чуть выше. Если хочешь можешь в личку/скайп стучаться.