Проверить на принадлежность к классу

[Appleman]

Друзья, ещё маленький частный вопрос к вам.

У меня в механизме проверки условий обращения идут по строковым идентификаторам, которые совпадают с геттерами проверяемого объекта. Например, имея массив условий на выполнение действия, записанный в формате {owner, propID, value}, нам для проверки достаточно установить owner-а, чтобы потом обратиться owner[propID] и сравнить полученный результат с value.

Вопрос, как проверить самого owner-a на принадлежность к тому или иному наследнику класса? И как записать это в массиве условий, подобно тому, как в моём примере выше? Спасибо.

[Wolsh]

Вообще не понял вопроса.

нам для проверки достаточно установить owner-а, чтобы потом обратиться owner[propID]

1. зачем "устанавливать"? Доступ же не типизированный.
2. не достаточно, чтобы класс был "правильным". Нужно еще, чтобы propID был существующим.

Если owner — экземпляр, то проверить класс можно if (owner is EnemySoldier) {}.
Но owner может быть и "статическим" классом? Надеюсь нет.

[Appleman]

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

Вообще не понял вопроса.

1. зачем "устанавливать"? Доступ же не типизированный.
2. не достаточно, чтобы класс был "правильным". Нужно еще, чтобы propID был существующим.

PropID - точно существующий, так как заранее известно, экземпляры каких классов проверяются. А "устанавливать" затем, что у меня в действии персонажи абстрактно заданы как атакующий и защищающийся. На этих местах могут быть как герой, так и враг или ещё кто-нибудь. Поэтому получив формулировку условий в форме {owner: IDs.STATUS_ATTACKER, propID: IDs.PROP_IS_WOUNDED, value:true}, прежде чем обращаться за значением, у меня выполняется такой метод в классе проверки условий действия:

protected function checkOwner(ownerID: String) : Character
{
switch(ownerID)
{
case IDs.STATUS_ATTACKER: return attacker; // Проверка по строковому ID и возврат экземпляра персонажа 
case IDs.STATUS_DEFENDER: return defender;
}

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

Если owner — экземпляр, то проверить класс можно if (owner is EnemySoldier) {}.

А как передать тот самый "EnemySoldier" в метод проверки условия? Вот так:

protected function checkCond(owner: Character, classID: String)
{
if (owner is classID) return true
}

не выходит. В этом и вопрос.

[ZergMaster]

Тоже не понял. Ты имеешь ввиду это?

protected function checkCond(owner: Character, classID: String)
{
if (owner == getDefinitionByName(classID)) return true
}

[СлаваRa]

Следующий шаг начать писать цепочки вызывов функций в конфигах. Очень интересно как автор рефакторит код? А ведь можно было сразу использовать что-то типа https://github.com/mayakwd/as3-vanilla-ice

[Appleman]

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

Тоже не понял. Ты имеешь ввиду это?

protected function checkCond(owner: Character, classID: String)
{
if (owner == getDefinitionByName(classID)) return true
}

ZergMaster, да, именно это. Благодарю. Не знал про такую штуку.

Сообщение от СлаваRa

Следующий шаг начать писать цепочки вызывов функций в конфигах. Очень интересно как автор рефакторит код?

СлаваRa, автор - зелёный новичок, который пытается реализовать давнюю мечту - написать игру, простите за пафос. А что смущает? Что я делаю не так? Поясни.

[Wolsh]

Не знал про такую штуку.

То есть ты написал полигры на строковых константах-идентификаторах, не зная как получить класс по его имени? О___о
(рабочий код)):

			var owner:Sprite = new Sprite();
			var ownerClass:Class = getDefinitionByName("flash.display.Sprite") as Class;
			trace(owner is ownerClass);

— А что смущает?
Ну, как бы, трудно рефакторить такую Лондонскую Библиотеку.
Компилятор понятия не имеет о том, что ты делаешь, ибо ты оперируешь строками а не классами и их свойствами и методами до последнего момента вызова — но и там нетипизированный доступ и компилятор возвращается ни с чем. "Расходимся".
Причем, всю эту непроверяемую компилятором кучу текста ты используешь, "чтобы ничего не забыть и не ошибиться". Когнитивный диссонанс настигает здесь.

[caseyryan]

Открой для себя интерфейсы. Очень полезная штука

[Appleman]

Wolsh, спасибо за код. Разобрался.

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

То есть ты написал полигры на строковых константах-идентификаторах, не зная как получить класс по его имени? О___о

Да, так получилось. Кстати, ты был тем человеком, который подсказал реализованный мной способ формулировки и хранения условий типа {owner, propID, value}. Правда я уже полностью ушёл от Обжектов и сделал по-ООП-шному класс ConditionEntity с пачкой наследников, переопределяющих метод проверки в зависимости от того, что и у кого проверяем. Их я запихиваю в вектор, заточенный именно на наследников класса ConditionEntity. Так что совсем уж лажу компилятор отлавливает.

— А что смущает?
Ну, как бы, трудно рефакторить такую Лондонскую Библиотеку.
Компилятор понятия не имеет о том, что ты делаешь, ибо ты оперируешь строками а не классами и их свойствами и методами до последнего момента вызова — но и там нетипизированный доступ и компилятор возвращается ни с чем. "Расходимся".
Причем, всю эту непроверяемую компилятором кучу текста ты используешь, "чтобы ничего не забыть и не ошибиться". Когнитивный диссонанс настигает здесь.

Всё, понял, на счёт чего критика. Ну всё-таки я оперирую строками исключительно в ситуации создания тех самых PropID для проверки условий. Вот кстати в соседней теме про статус-эффекты Tails точно также предложил искать эффекты по ID статуса.

А как ещё хранить ссылки на те или иные свойства объекта, кроме как строковой константой?

[caseyryan]

А как ещё хранить ссылки на те или иные свойства объекта, кроме как строковой константой?

Сделай интерфейс с нужными свойствами, и принимай в своем менеджере объект по интерфейсу, а не по классу. Класс может применять сколько угодно интерфейсов.

// класс применяющий интерфейс
public class Character extends Sprite implements ICheckable {
     public function Character() {
 
     }
    // применяем свойство из интерфейса
     public  function get hasForce():Boolean {
        return true;
     }
}
// сам интерфейс
public interface ICheckable {
     function get hasForce():Boolean;
}
// какой-то менеджер, которому нужно проверить есть ли у объекта свойство hasForce
 
public function setSomeObject(object:*):void {
         if (object is ICheckable) {
              var checkable:ICheckable = object as ICheckable;
              trace(checkable.hasForce); // 100% у этого объекта будет нужное свойство
         }
}

Вообще не вижу смысла хранить что-то в строковых константах.
Плюс интерфейсов в том, что их можно применить к любому классу. Допустим ты можешь легко применить один и тот же интерфейс и к наледнику Sprite и Sound или еще чего-то. И по типу интерфейса они будут одинаковы