Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flash > ActionScript 3.0

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 10.05.2018, 19:37
Zebestov вне форума Посмотреть профиль Отправить личное сообщение для Zebestov Посетить домашнюю страницу Zebestov Найти все сообщения от Zebestov
  № 91  
Ответить с цитированием
Zebestov
Lorem ipsum
 
Аватар для Zebestov

модератор форума
Регистрация: May 2001
Адрес: Одесса
Сообщений: 4,869
Записей в блоге: 4
В принципе стройненько все вышло, кроме одного момента:

1. Дочернему Вью его модель (дочерняя) передается сразу в конструкторе, ведь главный Вью имеет ссылку на главную модель и может передать все необходимое сразу.
__________________
Поймай яблоко 2!

Старый 11.05.2018, 12:21
ZergMaster вне форума Посмотреть профиль Отправить личное сообщение для ZergMaster Найти все сообщения от ZergMaster
  № 92  
Ответить с цитированием
ZergMaster
 
Аватар для ZergMaster

Регистрация: May 2008
Адрес: Питер
Сообщений: 385
Отправить сообщение для ZergMaster с помощью ICQ Отправить сообщение для ZergMaster с помощью Skype™
Цитата:
Сообщение от Appleman Посмотреть сообщение
Нормально, когда Модель вообще одна, а разные Контроллеры появляются в комплекте с разными Вью по необходимости?
Нормально. Просто не слишком удобно, если более-менее большой проект. У меня, как правило, главная модель является Фасадом для более мелких. Важно не делать лишних телодвижений, не делать "ООП ради ООП" - сначала делать одну модель. Как только видишь, что она превращается в небольшую портянку (больше двух экранов) - значит надо её декомпозировать и прятать в Фасад. Лучше, конечно, все это делать на этапе проектирования, но не всегда это удается. Это как с наследованием - функционал выносится в абстракции только тогда, когда в этом наступает необходимость.
__________________
while(live()) { hope(); }

Старый 12.07.2018, 17:01
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 93  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Друзья!

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

Понятно, что для карты/боя/магазина - свои Вью. Вопрос в том, как лучше реализовать общие компоненты. Рассматриваю варианты:
1. через наследование - создать Вью с общими компонентами и методами доступа к ним, а все остальные Вью наследовать от неё, тем самым делая эти методы также доступными. Тогда неважно, где игрок провёл очередной игровой час: в бою или в борделе - время обновится.
2. делать независимым классом, который будет подписываться на Модели карты/боя/магазина и вылавливать то, что касается обслуживаемых компонентов.

Что думаете?
Спасибо.
__________________
Не сломано - не чини!

Старый 13.07.2018, 12:34
ZergMaster вне форума Посмотреть профиль Отправить личное сообщение для ZergMaster Найти все сообщения от ZergMaster
  № 94  
Ответить с цитированием
ZergMaster
 
Аватар для ZergMaster

Регистрация: May 2008
Адрес: Питер
Сообщений: 385
Отправить сообщение для ZergMaster с помощью ICQ Отправить сообщение для ZergMaster с помощью Skype™
Я бы делал по 2-му варианту, следуя принципу модульности - чтобы можно было этот компонент использовать в других проектах.
__________________
while(live()) { hope(); }

Старый 02.10.2018, 15:29
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 95  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Друзья, ситуация:

1. Имею в Модели слот экипированного персонажу объекта (не обязательно предмет). Сам такой объект имеет свойства и статусы, отображаемые во Вью. Их состав может меняться в зависимости от типа;
2. При изменении свойств/статусов экипированного объекта Модель посылает событие, Вью по нему обновляет: выводит иконки рядом с окном экипированного.
3. Когда объект удаляется из экипированного, то работает следующая логика: если этот объект относится к самому персонажу (например, руки), то все статусы скрываются в окне экипированного и одновременно выводятся в окне персонажа, уже рядом с его портретом. А если экипированный объект - это предмет, то ничего никуда не нужно выводить.

Основанием для обновления Вью является событие от Модели. Сейчас оно приходит только при изменении значений свойств объектов. Поэтому при смене экипированных объектов события отправлены не будут, т.к. никакие их свойства не изменились. ДУмаю, как реализовать нужное мне поведение. Есть 3 варианта, но ни один мне не нравится:

1. На уровне Модели проверять, что за объект имеем и либо принудительно посылать соответствующие события в момент, когда он удаляется из экипированного, либо нет. Гарантированно даст нужный результат, но в моём понимании, нарушает принцип MVC, т.к. с т.з. Модели, совершенно по фигу, какие объекты как будет отображать Вью.
2. Сделать паблик в классе экипируемых объектов типа forcePropsRecheck(), который будет повторно посылать события на обновления Вью. Во Вью проверять, что за объект удаляется из экипированного и при необходимости дёргать этот паблик-метод. Тоже будет работать, но вроде как вмешательство в Модель со стороны Вью, хотя с т.з. состояния Модель не меняется. Только события переотправляет.
3. Всегда посылать события на обновления свойств и статусов экипируемого объекта из Модели: что при добавлении , что при удалении. Во Вью усложнять алгоритм обработки этих событий и по месту разбираться, что за объект, экипирован он или уже снят и т.д. Такой подход выглядит как самый правильный с т.з. принципов MVC, но самый геморройный.

Просьба прокомментировать. Спасибо.
__________________
Не сломано - не чини!

Старый 04.10.2018, 12:59
ZergMaster вне форума Посмотреть профиль Отправить личное сообщение для ZergMaster Найти все сообщения от ZergMaster
  № 96  
Ответить с цитированием
ZergMaster
 
Аватар для ZergMaster

Регистрация: May 2008
Адрес: Питер
Сообщений: 385
Отправить сообщение для ZergMaster с помощью ICQ Отправить сообщение для ZergMaster с помощью Skype™
коментирую: ничиво не поняль...
Вот где-то здесь мозг отключается полностью:
Цитата:
Поэтому при смене экипированных объектов события отправлены не будут, т.к. никакие их свойства не изменились
Можно как-то на примере?
__________________
while(live()) { hope(); }

Старый 04.10.2018, 14:58
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 97  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Да, пардон, я так и понял, что никто ничего не понял. Если честно, то я пока формулировал здесь в форуме, уже сам допёр, но всё равно было бы интересно увидеть комментарии.

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

Теперь игрок убирает кинжал. При выполнении соответствующего действия Модель посылает событие об изменении экипированного объекта, Вью убирает изображение кинжала и выводит изображение голых рук. При этом иконка "отравлено" должна пропасть и более нигде не выводиться.

Голые руки - это тоже отдельный объект, поддерживающий присвоение статус-эффектов. Допустим, мы тоже можем намазать их ядом (для рукопожатия смерти ). Программа отрабатывает точно так же, как с кинжалом: присвоение статус-эффекта Модели, событие, вывод иконки.

А теперь внимание. Мы опять меняем экипированный объект, выбрав что-то другое, т.е. "прячем" руки. Здесь по моему замыслу, Вью должна отрабатывать иначе, чем в случае с кинжалом. Так как руки - это непосредственно наш персонаж (по здравой логике, не по архитектуре), то все их статус-эффекты должны не пропадать, а оставаться на экране, только выводиться уже не рядом с окошком экипированного, а рядом с портретом.

То есть при идентичной ситуации, происходящей в Модели (смена экипированного объекта), Вью должна отрабатывать по-разному в зависимости от того, что это за объект. Вот так, надеюсь, понятнее.
__________________
Не сломано - не чини!

Старый 04.10.2018, 16:57
ZergMaster вне форума Посмотреть профиль Отправить личное сообщение для ZergMaster Найти все сообщения от ZergMaster
  № 98  
Ответить с цитированием
ZergMaster
 
Аватар для ZergMaster

Регистрация: May 2008
Адрес: Питер
Сообщений: 385
Отправить сообщение для ZergMaster с помощью ICQ Отправить сообщение для ZergMaster с помощью Skype™
А в чем проблема? Вроде как модели без разницы, что там во вью. В модели хранятся состояния экипировки: "голые руки", "кинжал", "без рук". У состояний, в свою очередь, есть свойства "отравленный", "ледяной", "огненный". То есть берем "кинжал", смотрим в свойства, видим, что он "отравленный" - тогда вью отображает иконки. Так же любые другие свойства. Если же это свойство не экипировки, а персонажа, то они висят все время в другом месте. Таким образом, например, присвоение "голым рукам" свойства "отравленный" может автоматически присваивать это же свойство персонажу.
Или я что-то не так понял
__________________
while(live()) { hope(); }

Старый 05.10.2018, 10:01
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 99  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Да, примерно так. Главная сложность была в том, что Вью требовались разные действий для разных типов владельцев одного и того же свойства.

Разумеется, весь алгоритм определения и отлова был создан во Вью.
__________________
Не сломано - не чини!

Создать новую тему Ответ Часовой пояс GMT +4, время: 17:37.
Быстрый переход
  « Предыдущая тема | Следующая тема »  

Теги
MVC , mvo , Проектирование
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 17:37.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.