реализация инвентаря и экипировки персонажа

[Appleman]

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

К слову, "false. Такого слота нет и не предвидится." это не null, a undefined.
И да, if(slot1 in dictionary){} будет проверять НАЛИЧИЕ свойства в словаре.

RedHead90, Wolsh, спасибо, действительно можно проверять наличие записи в Dictionary предложенными способами.

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

Чтобы идентификаторы не городить. Если есть SLOT_TORSO, SLOT_FEET и SLOT_TIT, и каждый в 2х слоях, то проще эти слои пронумеровать и добавлять, чем городить по 2 почти идентичных константы. Нет?

Зачем нужен Dictionary, я так и не понял. Чтобы записывать в него что-то, не предусмотренное классом-менеджером?)) А кто будет знать, что это что-то туда записали, и сможет его оттуда вытащить и учесть?
А упорядоченный набор свойств это просто порядок в проектировании. И то, что в данном случае этот список свойств (слотов) КОНЕЧЕН, однозначно намекает на неуместность "бесконечных" динамических коллекций — справочников и векторов.

Поясни, пожалуйста. Если мы можем проверить наличие САМОЙ ЗАПИСИ в словаре, то значит гарантируем себя от внепланового создания новых, и наш список слотов будет не менее постоянным, чем при создании отдельных свойств. Например, в конструкторе сразу напишем:

public function EquipmentManager()
{
_equipSlots[TORSO_ID] = null;
_equipSlots[LEGS_ID] = null;
}

и так далее. При добавлении шмотья первым делом проверяем, есть ли запись по такому ключу. Если undefined - то, пардон мадам, исключение. А тип получаемого значения мы ещё на входе метода putOn(item: Equipment) проверим.

[Wolsh]

Вопрос был "зачем?". Чем хранить это в Справочнике лучше, чем в приватных переменных? Что именно дает Справочник, конкретно пожалуйста?

[Appleman]

Задачи для менеджера экипировки в части слотов:
1. Создать конечный список слотов;
2. Организовать удобный и понятный доступ к самим слотам и их содержимому (записать/извлечь).
3. Проверять тип записываемых в слоты переменных;

Пока по ходу дискуссии вырисовывается, что справочник решает данную проблему с меньшим количеством писанины, чем создание приватных переменных. Оба варианта справляются одинаково (по крайней мере на мой дилетантский взгляд). Плюс действительно у справочника бОльшая гибкость. Если послезавтра меня осенит, что нужно изменить состав слотов, то пока в варианте со справочником это получится легче.

[Wolsh]

1. Создать конечный список слотов;

— Справочник не является конечным списком. Для контроля "конечности" требуются дополнительные проверки на наличие данного ключа.

2. Организовать удобный и понятный доступ к самим слотам и их содержимому (записать/извлечь).

Что может быть удобней и понятней чем _chestArmor = item;

3. Проверять тип записываемых в слоты переменных;

в putOn() никто не сможет передать что-то, отличное от Equipment.

Если послезавтра меня осенит, что нужно изменить состав слотов, то пока в варианте со справочником это получится легче.

Вы повторяете это как мантру, но я не вижу объяснения, чем легче? Гибкость Справочника в динамичности, то есть отсутствии контроля. Когда контроль не нужен, он дает преимущество в гибкости — то самое "пиши что хочешь". Но если ты собрался проверять, есть ли слот с таким именем, которое оказалось в списке занимаемых слотов Вещи, то ты должен сначала в коде создать в Справочнике слот с таким именем. Это отличается чем-то от создания переменной, кроме того что переменная будет нормально типизирована, в отличие от слота в Справочнике? Далее, тебе точно так же придется расписать все операции с этим слотом, без разницы.
Надо понимать одну важную особенность динамического кода: очень легко создать в объекте динамически (на лету) какое-то новое свойство. Проблема в том, что никто в другом месте кода об этом ничего не знает. Подумай об этом на досуге.
Ты можешь вообще сделать класс менеджера динамическим и создавать в нем слоты на лету. Вопрос в том, кто эти слоты потом сможет прочитать, кто будет знать, что вот такие слоты можно у него запросить.
И, если я оказался неубедителен в этом, то задумайся хотя бы над таким вопросом — а почему вообще Dictionary, если ключи будут исключительно строковые? Ведь вся "сила" Справочника именно в том, что ключами служат объекты а не строки и не числа. По строковым ключам достаточно тупого Обжекта.

[Appleman]

Wolsh, большое спасибо за объяснения. Надо с этим теперь пожить.

Единственный комментарий у меня прямо сейчас только на счёт вот этого пункта:

Надо понимать одну важную особенность динамического кода: очень легко создать в объекте динамически (на лету) какое-то новое свойство. Проблема в том, что никто в другом месте кода об этом ничего не знает.

Думаю, что я тут слабо чувствую разницу из-за выбранного мною подхода - использовать строковые ID, совпадающие с геттерами для передачи "адреса обращения" в качестве параметра. Согласись, что при таком подходе даже сама запись выглядит идентично: экземпляр[ключ]

Я, кстати, сделал работающий менеджер как раз "канонически", с использованием свойств. Но меня всё равно гложут сомненья.

[Wolsh]

1. На объявленное свойство ты можешь повесить сеттер, который будет что-то ДЕЛАТЬ при изменении значения, и геттер, который будет отдавать значение в удобном для спрашивающего виде (который может не совпадать с внутренним для класса форматом хранения — например, отдавать ID класса а не ссылку на экземпляр).
2. Объявленное свойство "само" контролирует Тип значения (ты получишь ошибку еще при попытке компиляции). Важный момент также, что тип значения точно известен там, где его будут запрашивать.
Все это называется Strongly-типизацией, в отличие от того что у тебя разрастается сейчас — Stringly-типизации. Тут хорошо бы знать меру. Одно дело айдишники предметов, позволяющие не создавать миллионы экземпляров предметов в памяти а оперировать короткими строками или числами до того момента, когда понадобится реальный экземпляр (а при умелой архитектуре он вообще будет нужен только во Вью — это то, о чем говорит Tails, реляционная БД, когда нет никаких экземпляров, а только данные в таблицах. Ну, типа есть айди вещи, и по этому айди ты можешь узнать ее название, тип, вес, резисты, цену и тп ИЗ ТАБЛИЦ, хранящих эти сведения по айди, а не из создаваемого "физически" экземпляра. Просто потому, что эта вещь не имеет ПОВЕДЕНИЯ, а только параметры и картинку, ей вообще не нужен Класс как таковой. Это как диалоги, ок? Просто упорядоченные по идентификаторам данные. Но совсем другое дело, когда ты начинаешь оперировать строковыми константами для обращения к "реальным" свойствам и даже методам настоящих живых классов, обеспечивающих то самое поведение над данными.

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

[Appleman]

Wolsh, спасибо за дополнительную аргументацию, всё намотал на ус.

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

1. На объявленное свойство ты можешь повесить сеттер, который будет что-то ДЕЛАТЬ при изменении значения, и геттер, который будет отдавать значение в удобном для спрашивающего виде (который может не совпадать с внутренним для класса форматом хранения — например, отдавать ID класса а не ссылку на экземпляр).

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

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

Я искренне признателен за такой подход. Думаю, не только я один.

[caseyryan]

Я тут решил слегка заоффтопить, но Appleman, а почему ты решил изучать флеш и делать игру именно на нем? Он же реально почти мертв, и уже абсолютно не востребован. Да и AS3 не дает достаточно хорошего представления о программировании в целом. В нем нет целой кучи всего, что во многих других языках (популярных и востребованных) давно считается нормой и обыденностью. Я, после перехода с as3 на C#, быстро осознал на сколько он круче) Сейчас на as3 даже возвращаться не хочется. Жалею только, что хотя бы года на три раньше этим не занялся

[Appleman]

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

[caseyryan]

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