Хорошее MVC

[etc]

Сообщение от Psycho Tiger

1) Вот классы выше - теперь это правильное MVC?

В целом на то, как это делал бы я, уже похоже.

Сообщение от Psycho Tiger

2) Да, действительно - вьюшка может менять что нибудь у модели и контроллер сойдёт с ума - получается, у этой триады даже пиша вьюшку надо быть аккуратным, потому что можешь всё сломать?

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

Сообщение от Psycho Tiger

3) А кто от кого наследуется? Я так понимаю: controller -> Object, model - EventDispatcher, viewer - DisplayObject. Так?

Чаще всего — да. Но и контроллер тоже может события рассылать.

Сообщение от Psycho Tiger

4) Модельку передавать в конструктор вьюшки это хорошая практика, или всё таки лучше через сеттер? (вопрос граничит с бредом, знаю )

Это зависит от задачи, если планируется переиспользование вьювера для отображения различных данных, то сеттер предпочтительнее.

Сообщение от Psycho Tiger

5) На той же википедии и на некоторых других сайтах пишут, что контроллер - лишь связующее, а вся бизнес логика в модели. Они не правы или с флешем тонкость какая?

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

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

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

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

Что касается «оригинальности», то достаточно картинки с Википедии:

Совершенно точно у View есть ссылка на модель.

У модели нет конкретной ссылки на представление. Ссылка на уровне приложения конечно есть, но она лишь на уровне подписчика на изменения, поэтому и выполнена пунктиром.

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

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

Сообщение от Psycho Tiger

7) Насколько это хорошая практика - делать по 40 разных событий для 40 изменений - то есть, если изменился угол поворота чей нибудь - не обновлять положение в пространстве, а лишь повернуть (то есть разбиение например updatePositionEvent на updateXYPositionEvent и updateRotationEvent)

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

Сообщение от Psycho Tiger

8) Если передается только интерфейс, тогда вся инфа об обновлении должна поступить вместе с Event`ом, а не через геттеры от модели о нужной информации?

А что мешает описать геттеры и в интерфейсе? Менять не можем, а читать вполне себе да.