AS3 Любопытный вопрос по структуре

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

Классы, которые содержат только статические константы, например:

package //?
{
    public class Elements
    {
        public static const FIRE:String = "fire";
        public static const WATER:String = "water";
    }
}

Которые, очевидно, используются в таких ситуациях:

var myElement:String = Elements.FIRE;

Я всегда размещал эти классы в пакетах, содержащих другие классы, которые максимально используют их. Например, этот класс может быть в game.mobiles, потому что этот пакет содержит классы для мобильных устройств (игрок, враги и т. д.), которые максимально используют Elements; у них есть сопротивления и повреждения, которые могут быть стихийными.

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

Я начал задаваться вопросом, должен ли я поместить все мои классы, подобные приведенным выше, в общий пакет, такой как game.statics, хотя с некоторых точек зрения это кажется таким же беспорядочным.

Что я должен сделать здесь, чтобы иметь как можно более чистую и понятную структуру, когда дело доходит до этих маленьких классов?


person Marty    schedule 30.05.2011    source источник
comment
Оружие и доспехи будут иметь стихийные свойства, но они будут упакованы в game.items.equipment.(оружие/броня). Это хороший пример того, что класс Elements также будет очень нужен, но размещение его внутри game.items кажется еще более странным.   -  person Marty    schedule 31.05.2011
comment
Марти, я сделал это, как и ты в большинстве случаев. У вас есть классы оружия/доспехов с атрибутами стихий? Если вы просто рассматриваете оружие/броню как часть классов Player и Enemy, это как бы создает ситуацию, когда они напрямую зависят от Elements. Они ЯВЛЯЮТСЯ частью ваших мобильных телефонов по вашему определению и связаны с ними.   -  person prototypical    schedule 31.05.2011
comment
извините, удалил комментарий, чтобы добавить к нему. Если оружие/доспехи обрабатываются в своих классах, мобильным устройствам не нужно знать, что они существуют. Я ходил по этой дороге не раз :) Меня это тоже беспокоит. Но это имеет больше смысла как атрибут предмета, чем мобильный атрибут. На самом деле все зависит от того, как далеко вы хотите зайти :)   -  person prototypical    schedule 31.05.2011
comment
Будут ли предметы, помимо снаряжения, обладающие стихийными эффектами?   -  person prototypical    schedule 31.05.2011
comment
Я не уверен, что вы имеете в виду, базовый класс для мобильных устройств и базовый класс для предметов будут активно использовать элементы. Вы говорите, что поскольку доспехи и оружие имеют урон и защиту, основанные на элементе, классу мобильных не нужно много использовать сами элементы?   -  person Marty    schedule 31.05.2011
comment
Не зная вашего игрового дизайна. А как насчет элементов, влияющих на ваш мобильный телефон? Если у оружия и доспехов есть стихийные атрибуты, урон рассчитывается на их основе. Возможно, все, что нужно вашему мобильному телефону, это знать, каковы его повреждения. Не как и почему.   -  person prototypical    schedule 31.05.2011
comment
Верно, но подумайте, как интенсивно я буду использовать Elements.X в базовом классе для мобильных устройств. например ИИ некоторых врагов может корректировать свою тактику в зависимости от вашего сопротивления. if(target.resistances[Elements.FIRE] › 0.6) dontUseFire();   -  person Marty    schedule 31.05.2011
comment
ну разве это не сравнение имеющегося в вашем распоряжении оружия с броней цели? Я предполагаю, что я клоню к тому, что вы можете получить очень подробную информацию. Это вопрос того, насколько подробно вы хотите получить. Я часто попадаю в ситуацию, которую вы описываете, и говорите, что в каком-то смысле это не имеет смысла. Но смысл в том, что это имеет смысл - может быть гораздо больше работы :)   -  person prototypical    schedule 31.05.2011
comment
Кроме того, разве снаряды не нанесут элементальный урон?   -  person prototypical    schedule 31.05.2011
comment
Может быть что угодно. Как я уже сказал, эти константы будут использоваться на протяжении всей игры — я просто хотел классифицировать это лучше, чем там, где это больше всего необходимо.   -  person Marty    schedule 31.05.2011
comment
поэтому, если вы следовали тому, что я говорил, игроку не нужно было бы знать об элементе. Вы даже можете сделать шаг вперед и сделать так, чтобы у игрока была система оружия, функция которой заключалась бы в принятии этих решений. Теперь классу игрока даже не нужно знать о конкретном оружии. Ваш игрок может просто сказать --- эй, оружейная система, вот моя цель. Какой лучший вариант у вас есть?   -  person prototypical    schedule 31.05.2011
comment
Верно, но в какой-то момент мобильным устройствам потребуется использовать этот класс. Класс Element ничего не делает, он просто более аккуратно хранит строки. Я мог бы легко отказаться от класса Elements и просто использовать огонь и т. Д., Просто это выглядит некрасиво.   -  person Marty    schedule 31.05.2011
comment
ООП заключается в устранении зависимости/связи, чтобы код был более переносимым. Как далеко вы пойдете, зависит от вас. время/усилия входят в это уравнение. Вы можете устранить необходимость для вашего игрока даже знать, что такое элемент. Я точно знаю, что вы имеете в виду, что выглядит некрасиво. С играми больше, чем с приложениями, я обнаружил, что рисую линию быстрее — если только вы не планируете расширять игру с течением времени или сосредоточены на использовании кода в других проектах. Итак, я нашел способ жить в гармонии с такими классами, как Elements, которые отстают.   -  person prototypical    schedule 31.05.2011


Ответы (2)


Я думаю, что ваш существующий метод правильный, поскольку он наиболее логичен. Обычно вы не видите (в обычных архитектурах) классы, которые содержат ТОЛЬКО статические/постоянные переменные. Обычно вы видите их в комплекте с классом, в котором существует функциональность, которая больше всего использует эту статику. Например, любой из классов Events в AS3. Вы увидите статическую константу MouseEvent.MOUSE_DOWN и т. д., связанную с фактическим классом событий (MouseEvent). Я думаю, что разделение их в пакет, который существует исключительно для хранения статики, было бы менее логичным, хотя это не обязательно было бы неправильно. В любом случае, если бы вы следовали примеру чего-то установленного, я бы посмотрел на сам язык AS3 в качестве примера, и в этом примере мы видим, что команда flash core, похоже, собирает классы в пакеты с наивысшим уровнем ассоциации. Я думаю, возможно, ваши сомнения в этом возникают из-за того, что у вас есть класс, состоящий исключительно из констант, без функциональности или наследования, которое явно связывает или связывает класс (ы) с чем-либо еще.

person Community    schedule 30.05.2011
comment
Это имеет смысл, хотя даже AS3 сталкивается с моей ситуацией. Взгляните на класс StageScaleMode, который упакован в flash.display. Для меня это логично, потому что он тесно связан с дисплеем и нужен только для установки свойства scaleMode в рабочей области, которая также упакована в flash.display. Суть моего примера в том, что на элементы можно ссылаться на протяжении всей игры (для отображения информации на листе вашего персонажа, например, fireResist.text = player.resistances[Elements.FIRE]; и так далее. - person Marty; 31.05.2011
comment
Да, я понимаю дилемму, это немного странный класс. Обычно, когда я вижу подобный класс в других работах, они, как правило, помещаются в пространство имен, такое как mydomain.core.XXX. Я не знаю, как я уже сказал, я не думаю, что размещение его в собственном пакете/пространстве имен обязательно будет неправильным. Возможно, кто-то еще может иметь немного больше информации. - person ; 31.05.2011
comment
Звучит настолько реалистично, насколько я могу, на самом деле. Спасибо, что поддержали мою текущую структуру — думаю, мне придется придерживаться ее. - person Marty; 31.05.2011

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

person Joshua Sullivan    schedule 30.05.2011
comment
Не могли бы вы подробнее рассказать о том, что вы имеете в виду под последним предложением? не люблю функции... - person Marty; 31.05.2011
comment
Ну, если класс A ссылается на константу в классе B, то любой SWF-файл, в котором используется класс A, также нуждается в копии класса B в нем, что затем требует, чтобы все классы, на которые ссылается класс B, были там ... он может складываются в ситуациях, когда желателен небольшой размер файла. Если оба класса A и B ссылаются на константы в простом классе C, то нет каскада дополнительных ссылок на классы, когда либо A, либо B используются сами по себе в файле. - person Joshua Sullivan; 01.06.2011