| ||||||||
| ||||||||
|
|
|||||||||||||||||
|
|
31.10.2013, 16:26
|
|
||||
 |
Цитата:
__________________
Кто к нам с чем для чего - тот у нас того от того. |
|
31.10.2013, 16:34
|
|
||||
 |
Dukobpa3 - ну а чем же оно будет отличаться от обычного контроллера? Никто не поймет именно почему назвали МЕДИАТОР тогда - что в нем особенного? Весь смысл в том, что походу вы сами не понимаете в чем его суть, по скольку сначала говорите верные вещи, а когда доходит дело до реализации - получается, что медиатор такой же стандартный контроллер как и все. Он слушает события от вью ( все контролы могут слушать от вью) , он запихивает модель во вью ( все контролы так делают, почему нет?) . Рулить паблик методами - так же может любой контроллер - по MVP. А вот слушать модель - это уже интересно. Для чего контролу слушать модель? что он может от этого вынести для себя?
__________________
Марк Tween |
|
31.10.2013, 17:13
|
|
||||
 |
Цитата:
Цитата:
__________________
משיח לא בא משיח גם לא מטלפן |
|
31.10.2013, 16:38
|
|
||||
 |
Ну, медиатор, например, не меняет модель напрямую.
Я Dukobpa3'a почему - то понимаю )
__________________
Тут мужик танцует и поёт про флэш |
|
31.10.2013, 16:43
|
|
||||
|
|
Цитата:
 Я вроде нигде сам себе не противоречил потому последнего комментария не понял в свой адрес. Медиатор это не контроллер. Медиатор это по сути своей вью. Но вместо того чтобы рисоваться на екран самому - он помогает рисоваться своим детям. На этом его обязанности заканчиваются. И с точки зрения того же контроллера или "системы" - как я назвал этот уровень абстракции - медиатор это вью. Т.е. он обязан выполнять все фнукции вью для системы: - слушать модель. - диспатчить в контроллер. Медиатор может оставить модель внутри себя, и рулить вьюхой напрямую через паблик методы, не позволяя ей думать вообще. Может отдать модель или часть модели вьюхе, тогда вьюха сама отрисуется, и медиатор возьмет на себя более глобальные визуальные задачи, например смену стейтов вьюхи, если их несколько и в таком духе. Тем самым медиатор инкапсулирует в себе все внутренности архитектуры нашей вьюхи, или нескольких.
__________________
Кто к нам с чем для чего - тот у нас того от того. |
|
31.10.2013, 16:43
|
|
||||
|
|
Ладно, придумал минимальный пример:
Есть игра, в которой можно управлять чуваком самому или им может управлять компьютер. Сам чувак, который умеет бегать влево-вправо (менять свою координату, показывать анимацию) – вью. Медиатор 1: компьютер. Медиатор 2: игрок. С точки зрения вью: она не знает, кто им управляет. Это может быть хоть виртуальный шлем для котейки. С точки зрения контроллера: он не знает, кто им там управляет. Да ему и по барабану.
__________________
Тут мужик танцует и поёт про флэш |
|
31.10.2013, 16:44
|
|
||||
|
|
Цитата:
В идеале контроллер не должен этого делать. Максимум это спрятать/отобразить вью. Но рисоваться и обновляться она должна сама, иначе никакого профита от мвц не будет. Добавлено через 4 минуты Цитата:
Медиатор компа эмулирует клики, а дальнейшая схема работает как и с живым игроком - контроллер получил клик, отдал модели, модель поменялась вью отрисовалась. //****************** Просто я бы сразу сделал либо два режима работы контроллера. Либо два контроллера. Короче добавил бы че-то более массивное и более приспособленное для тяжелых вычислений. Моя логика ИИ была бы в какой-то связке контроллер-модель. Но не в медиатор-вью. Добавлено через 14 минут Т.е. я бы эмулировал не несуществующие клики, а уже готовые решения модели либо контроллера на основании несуществующих кликов.
__________________
Кто к нам с чем для чего - тот у нас того от того. |
|
31.10.2013, 17:08
|
|
||||
|
|
Для пятнашек я бы обошелся одним контроллером и двумя медиаторами
- контроллер ВСЕГО - медиатор интерфейса - медиатор игрового поля
__________________
Кто к нам с чем для чего - тот у нас того от того. |
 |
 |
Часовой пояс GMT +4, время: 01:28. |
|
|
« Предыдущая тема | Следующая тема » |
|
|
Комбинированный вид
