Хорошее MVC

[Zebestov]

fish_r, ты действительно не сказал ничего, что оспаривал бы Dukobpa3. Особенно легко в этом убедиться, прочитав пропущенный тобой комментарий прямо над твоим возражением.
Вы об одном и том же разными словами

[fish_r]

Я его и не пропустил. Мы обсуждали другую частность:

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

В данном случае координаты это часть модели карты, поэтому они в модели быть должны.

[Zebestov]

Ясно. И как это

координаты это часть модели карты, поэтому они в модели быть должны

противоречит этому

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

Координаты юнита на карте разумеется должны храниться/изменяться в модели (вы оба придерживаетесь схемы, где модель — это данные и логика по их обработке). Вьюха может быть чем угодно (2D, 3D, забавным мультиком, диаграммой посещаемости "храма" юнитами за отчетный период, и т.д.). И модели до этого нет никакого дела. Она живет своей жизнью.

А вот это действительно лишнее:

Модель не должны интересовать координаты объекта.

[fish_r]

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

А вот это действительно лишнее:

Вот это вот действительно лишнее.

Хорошо. Предположим вы делаете не игру, а польз. интерфейс заносите ли вы координаты кнопок в модель?

[Zebestov]

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

Хорошо. Предположим вы делаете не игру, а польз. интерфейс заносите ли вы координаты кнопок в модель?

Ну и на этот вопрос тебе Dukobpa3 уже давал ответ, с которым я согласен

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

Юнит — не кнопка. Юнит — фигурант логики приложения. Кнопка — кликабельный кусок монитора.

[Dukobpa3]

@Zebestov - Спасибо, наверное))) Мои слова поняты верно и с первого раза, плюс за поддержку.

@fish_r - Слушай что тебе старшие говорят ;-Р

[HardCoder]

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

Добавлено через 2 минуты
Или лучше создать несколько таких событийных классов, погрупировав в них лишь те свойства, которые непосредственно будут нужны при поимке этого события в представлении?

[Zebestov]

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

...при диспатче из модели передавать все доступные параметры для вьюшки. Это будет правильно?

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

[Dukobpa3]

Вьюшка не может изменять модель. Но у нее есть ссылка на модель

да

Если создать событийный класс для событий модели

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

Акцессоры здесь не подходят

Очень даже подходят. Просто вью ничего не меняет в модели, только читает всё что ей нужно. А контроллер может еще и менять. Технически это разделить сложно, хотя можно, там придется неймспейсы прикручивать. Я на практике просто сам сознательно не трогаю модель из вью и всё.

Т.е. получается модель продиспатчила - меня изменили. Вью полезла посмотрела нужные данные и всё.

Добавлено через 3 минуты

Не правильно. Вьюшка просто услышит про изменения и сама пойдет к модели выяснять

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

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

Добавлено через 8 минут

Ей даже не важно, кто и каким образом поменял эти значения

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

[HardCoder]

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

Ей даже не важно, кто и каким образом поменял эти значения (модель сама там что-то насчитала, контроллер что-то там вызвал, с сервера данные подоспели).

Это понятно. Я же не говорю что она должна знать кто что менял.

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

Не правильно. Вьюшка просто услышит про изменения и сама пойдет к модели выяснять, что там поменялось.

Жаль что не правильно. Яхотел просто вьюшку подписать на события модели и больше модель в ней вообще не трогать. Что-то типа этого:

model.addEventListener(ModelEvent.UNIT_ACTIVATED, activateUnit);
private function activateUnit(e:ModelEvent):void {
      trace(e.activeUnit);
}

То есть, чтобы за свойством activeUnit не лезть в модель с которой по-пьяни можно сделать что-то, а получить его прямо из событийного обьекта ModelEvent.
Что же, будем делать "правильно". Спасибо

Добавлено через 8 минут

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

Сложно будет сделать адекватный рендер с обработкой всех событий и слишком легко запутаться..

Не совсем понял. У меня какбэ все просто. Есть класс ModelEvent, на события которого подписываются две вьюшки, вернее одна вью - и компьютер(АI). Они получают такие события от модели. Отправляют в контроллер события OpponentEvent.