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

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

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 22.11.2018, 15:31
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 1  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
По умолчанию Вопрос про наследование и State

Друзья!

У меня в архитектуре предусмотрены методы, переопределяемые для персонажа игрока и NPC. Это реализовано через наследование: классы CharacterPlayer и CharatcterNPC расширяют общий базовый Character.

Также у Character некоторые методы работают по-разному в зависимости от того, находится он в "обычном" или "боевом" режиме. Реализовано через паттерн проектирования "Состояние" (State). В частности, создан класс ChState и его наследники ChStateNormal и ChStateBattle. Экземпляр текущего состояния получает в конструктор ссылку на персонажа-владельца и записывается у него в переменную _state, через которую вызываются все различающиеся методы. Всё как в книжке.

Теперь вопрос. Что мне делать, если вызываемая версия метода зависит одновременно и от наследника Character (игрок/NPC), и от текущего состояния (Normal/Battle)?
__________________
Не сломано - не чини!

Старый 23.11.2018, 15:58
Rzer вне форума Посмотреть профиль Отправить личное сообщение для Rzer Посетить домашнюю страницу Rzer Найти все сообщения от Rzer
  № 2  
Ответить с цитированием
Rzer
 
Аватар для Rzer

блогер
Регистрация: Feb 2007
Адрес: Spb
Сообщений: 612
Записей в блоге: 8
Отправить сообщение для Rzer с помощью ICQ
Ты всегда можешь в коде проверить, какое именно состояние или персонаж у тебя используются, например:

Код AS3:
override function doSomething():void{
   if (_state is ChStateNormal) doSomethingNormal();
   else doSomethingBattle();
}

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

блогер
Регистрация: Feb 2008
Адрес: http://playtika.com
Сообщений: 1,119
Записей в блоге: 5
Отправить сообщение для СлаваRa с помощью ICQ Отправить сообщение для СлаваRa с помощью Skype™
по-моему паттерны подобного рода были придуманы специально, чтобы не делать таких вот проверок...
__________________
местонахождение

Старый 23.11.2018, 16:19
Rzer вне форума Посмотреть профиль Отправить личное сообщение для Rzer Посетить домашнюю страницу Rzer Найти все сообщения от Rzer
  № 4  
Ответить с цитированием
Rzer
 
Аватар для Rzer

блогер
Регистрация: Feb 2007
Адрес: Spb
Сообщений: 612
Записей в блоге: 8
Отправить сообщение для Rzer с помощью ICQ
Всё равно тебе придётся узнать в каком режиме находится стейт.

Можно сделать и так:

Код AS3:
class State{
 
   public static const NORMAL:String = "normal";
   public static const BATTLE:String = "battle";
 
   function getStateType():String {
     return NORMAL;
   }
}
И переопределять этот метод в детях:

Код AS3:
class BattleState{
  override function getStateType():String {
     return State.BATTLE;
   }
}
И проверять в коде:
Код AS3:
override function doSomething():void{
   if (_state.getStateType() == State.NORMAL) doSomethingNormal();
   else doSomethingBattle();
}
Но я не вижу принципиально разницы, если все твои последующие стейты ты будешь наследовать от ChStateNormal или ChStateBattle

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

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от Rzer Посмотреть сообщение
Всё равно тебе придётся узнать в каком режиме находится стейт.
Вовсе нет. Как отметил СлаваRa, суть самого паттерна "Состояние" в том и состоит, что проверять ничего не нужно. Ты просто записываешь в переменную _state того или иного наследника базового класса (или интерфейса) состояния и переопределяешь в нём методы. Получается, что вместо doSomething(), ты запускаешь _state.doSometing(). По факту запустится метод из актуального на данный момент состояния.

Цитата:
Но я не вижу принципиально разницы, если все твои последующие стейты ты будешь наследовать от ChStateNormal или ChStateBattle
Пока ничего не придумал лучше, чем создать 4 варианта наследников: ChStateBattlePlayer, chStateBattleNPC и аналогично для "обычного" состояния.
__________________
Не сломано - не чини!

Старый 24.11.2018, 18:04
Rzer вне форума Посмотреть профиль Отправить личное сообщение для Rzer Посетить домашнюю страницу Rzer Найти все сообщения от Rzer
  № 6  
Ответить с цитированием
Rzer
 
Аватар для Rzer

блогер
Регистрация: Feb 2007
Адрес: Spb
Сообщений: 612
Записей в блоге: 8
Отправить сообщение для Rzer с помощью ICQ
Главное не заработай себе болезнь паттернов. То что ты делаешь сейчас скорее всего большее зло чем просто добавить проверку.

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

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Цитата:
Теперь вопрос. Что мне делать, если вызываемая версия метода зависит одновременно и от наследника Character (игрок/NPC), и от текущего состояния (Normal/Battle)?
Так а в чем проблема-то?
У состояния есть ссылка на персонажа. Состояние знает, что у персонажа есть какой-то метод.
Этот метод вызывается. Профит. Состояние Battle вызывает метод hit(), состояние нормал вызывает метод fuckAbout(). Какая состоянию разница что делается внутри этого метода?
Мне кажется, что иногда ты создаешь тему сразу же, как что-то не понял. Даже не успев подумать а есть ли вообще проблема
__________________
Ко мне можно и нужно обращаться на ты)

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

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
caseyryan, на счёт последнего ты не прав. Напротив, с понедельника крутил в голове. Здесь скорее зашоренность: прочитал в книжке, как методы реализуются ВНУТРИ классов-состояний и ни шагу в сторону. Спасибо за совет!

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

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

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Цитата:
Скажи ещё, как по-твоему, если состояния действительно имеют ссылку на своего владельца, как вообще лучше делать: реализовывать что-то в состояниях, или использовать их как классы-"стрелочники", которые дёргают нужные методы владельцев, а сами ничего не делают?
По-моему, если задача состояния только в том, чтобы определить какой метод дернуть, то оно в принципе не нужно. Достаточно сделать несколько констант, обозначающих состояние и простым свитчем выбирать какой метод дернуть.
В то же время, если состояние для каждого вида врагов будет содержать какую-то вшитую логику, то это тоже гибкости не придает.
Поэтому, я бы на твоем месте остановился на варианте с константами.
Но это мое имхо, решать как делать всё равно тебе
__________________
Ко мне можно и нужно обращаться на ты)

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

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
caseyryan, я наоборот с этого начал и потом ушёл, т.к. слишком раскидистой начала становиться реализация подобной логики. Состояние по факту оказалось достаточно комплексной штукой, влияющей на многие вещи. Это в данном конкретном случае потребовалось дёргать методы.
__________________
Не сломано - не чини!

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

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

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


 


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


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