Ищу правильный подход к решению задачи. (Куда копать?)

[Slant]

Не хочется изобретать велосипед - не верю что подобные задачи не имеют общепринятых принципов решения. А вот знания о них мне и не хватает. Итак:

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

Как подошел к решению:

Имеется класс Backpack - со свойством в виде массива из BaseItem, и с методами позволяющими добавить удалить или использовать один из объектов типа BaseItem.

Имеется класс BaseItem - общий класс описывающий что такое предмет. Без конкретики. У него есть такие свойства как вес, и т.д. И метод doUse - в котором описано что предмет делает когда его применяют. У этого, базового класса - пустой.


Имеется набор классов с собственно предметами, расширяющие класс BaseItem. Для примера - MediKid extends BaseItem.

В нем добавлены пара свойств характерных только для него, и обязательно переопределяется метод doUse - у каждого предмета действие свое.

Вроде бы получается стройная система. Есть только одно "но": как сгенерировать новый предмет на основе обстановки в игре, если данные об обстановке у меня предполагаются XML? Т.е. я не могу прямо записать в описании комнаты кусок кода - Backpack.addItem = new MediKit; ...

В в описании обстановки может быть только текст (ну или несколько полей с текстом - не суть важно). А хочется чтобы получив этот текст и найдя в нем название класса "MediKit" (написаный текстом - String) некая функция могла вернуть мне новый экземпляр MediKit, который можно будет запихнуть в рюкзак и т.д. Это вообще возможно сделать не закапываясь в костыли с тупым перебором всех возможных вариантов названий через swicth или последовательности else if?

Не прошу готовое решение - просто, если кто хотя бы знает каком направлении гулгить, подскажите пожалуйста. За что зацепится? Может существует что-то типа JavaScript-овского eval...

[Jewelz]

если верно понял вам нужна ф-я getDefinitionByName, почитайте flash.utils

[gloomyBrain]

За что зацепится?

за getDefinitionByName(), примерно так:

import flash.utils.getDefinitionByName;
 
...
 
var className:String = "MediKit";
var ClassRef:Class = getDefinitionByName(className) as Class;
 
if(ClassRef) return new ClassRef();
return null;

PS
Такой подход работает, если ресурсы расположены в одном ApplicationDomain с исполняемым кодом (код и ресурсы в одном swf). Если это не так, делайте то же самое через ApplicationDomain#getDefinition()

[nOobCrafter]

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

[Slant]

О да, getDefinitionByName это как раз то, что нужно. Огромное спасибо.

А интерфейсы... Я задумывался, но у меня там выходит сильно завязано на базовый класс. Львиная доля функционала именно в нем, в классах конкретных предметов за исключением doUse, лишь дополнения, причем практически все - нестандартные получаются. Наследование как-бы само просится на логику работы...

[gloomyBrain]

Наследование как-бы само просится на логику работы...

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

Итак, ложка должна
- уметь воспринимать информацию
- уметь летать
- отличать лавровый лист от всего остального
- понимать когда человек наелся
- понимать когда суп кончился
- ...

А не многовато ли это для обычной ложки? =)
Извините за такую абстракцию, но суть в том, что должен быть кто-то, кто умеет и знает как использовать предмет и должен быть сам предмет. Эти 2 понятия никак не могут сочетаться. По сему замечание про фабрику очень уместно - с её помощью можно формировать команды и отдавать их "исполнителю". Исполнитель, глядя на команду что-то делает. Исполнитель может меняться, все зависит от команды (и, соответственно, от предмета), однако, он в любом случае должен уметь применять предмет.
Что же касается самих предметов, то они, в моем понимании, должны быть не более чем набором данных, из которого можно сформировать команду.

[Slant]

Извините за такую абстракцию, но суть в том, что должен быть кто-то, кто умеет и знает как использовать предмет и должен быть сам предмет. Эти 2 понятия никак не могут сочетаться.

А почему собственно? Ну, допустим, ложка - да. Кусок метала, сама нифига не умеет. А если, это таблетка? В ней находится некое вещество которое начнет реагировать как только окажется в желудке. А чей это желудок - таблетке все равно. Вот и у меня реализация работы предметов - по этой логике. Если предмет может что-то делать при активации - он это и будет пытаться делать. Результат зависит от окружения, но при этом не нужно заранее знать все возможные варианты. Т.е. для той-же таблетки - если организм который ее принял подходит - она его вылечит. Если нет - ничего не произойдет. Или модифицируем поведение - неподходящий организм умирает. Тут мне в коде надо делать только одну проверку. На наличие подходящих условий у потребителя. Кем бы он не был. А если у него их нет - совершенно все равно что у него там еще есть...

Исполнитель, глядя на команду что-то делает. Исполнитель может меняться, все зависит от команды (и, соответственно, от предмета), однако, он в любом случае должен уметь применять предмет.

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

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

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

[mayakwd]

Я бы лучше сделал хэш, пожалуй, вместо getDefinitionByName.

[gloomyBrain]

каждому, свой вариант реакции на попытку одеть штаны?

Каждому - свой вариант применения предмета. Например - штанов.

А чей это желудок - таблетке все равно

Кто ее съел, тот ее и переваривает. По сути - та же команда.

А вообще любые аналогии - это аналогии. Я говорю о том, что предмет не может сам взять и примениться. Он должен быть кем-то применен. Как он будет применен - зависит от исполнителя. Согласитесь, в реальной жизни это так.

[Slant]

Каждому - свой вариант применения предмета. Например - штанов.

Нда. Даже не знаю что сказать. Тут ведь как раз обратная логика - имеем штаны. Надеваем. Штаны либо одеваются, либо нет. Целыми оденутся нормально только на человеке. Итого - для обезьяны, собаки, мыши, мы должны вписать три заведомо ненужных куска кода? А если потом появятся еще кошки? Ящерицы? Всем им, заведомо не носящим штаны придется вписывать код, единственная задача которого - ничего не делать, убедившись что применяем к ним штаны?

Тогда как если проверка выполняется штанами - это один простой кусок кода, который всегда даст нужный ответ, даже с теми существами которых на момент проектирования штанов еще не было. И если появится производная от человека, скажем китаец, штаны на него будут одеваться автоматически.
На мой взгляд, если объектов на которые может применяться предмет, может быть много, причем применение возможно только на строго определенные, то как минимум проверку должен проводить сам предмет, если не хотим лишнего кода. Функционал можно и перенести, но такие вещи как всегда одинаковое действие вещества таблетки, тоже, логичнее на мой взгляд описывать в самой таблетке. От исполнителя не зависит, будет это вещество вообще работать, или нет. Будет. Как - вопрос другой. Если один из вариантов подразумевает ответ "у всех остальных - так", и этих остальных может быть на порядок больше, то этот функционал - хороший кандидат на описание прямо в предмете. Особенно если он еще и несложный. По моему так.

Кто ее съел, тот ее и переваривает. По сути - та же команда.

Да не верно это. Смысл не в том, что ее переварят, это могут сделать все. А суть в том, что ее вещество активируясь всегда, эффективно только для определенного организма. Остальные - идут лесом.

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

Не соглашусь. Применение предмета имеет две фазы. В первой - мы решаем, и выполняем необходимые для применения действия. Умные люди еще проверяют - а стоит ли. Например - не стоит чиркать спичкой рядом с бензином. Глупый может не проверять. Но результат от этого не изменится, если чиркнуть - спичка все равно загорится (последствия - это другое дело). А вторая фаза - это то, что предмет делает будучи примененным. Таблетка - активирует вещество которое будет поглощено организмом, спичка - горит, и т.д. Это предмет как раз делает сам. Часть его сути. И именно описание второй фазы удобнее хранить в самом предмете. На мой взгляд.