Форум Flasher.ru - Большое количество свойств

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)

- - Большое количество свойств — что делать? (http://www.flasher.ru/forum/showthread.php?t=214762)

Большое количество свойств — что делать?

Друзья! Уже спрашивал в "своей" теме по проектированию текстового квеста, но поскольку предыдущий ответ был моего авторства, новый вопрос "пристегнулся" следом и, по всей видимости, по этой причине остался без внимания. Задам отдельно. Если неправ по части создания новой ветки, просьба модераторам строго не судить и ветку удалить.

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

Как посоветуете лучше сделать: продолжать добивать такие свойства в основной класс или создать новый класс, например, CharacterBattle, куда экземпляр Character будет включён методом композиции, и уже в него добавлять нужные свойства? Чтобы экземпляр этого CharacterBattle создавался Моделью при запуске мини-игры и исчезал с её окончанием. Интересует аргументация с т.з. как расходования ресурсов, так и общепринятых правил, "хорошего тона" программирования. Спасибо.

Конкретно в данной ситуации я думаю создание класса CharacterBattle вполне оправдано, как сущность, которая используется в рамках Battle.

Спасибо, wolsh, за комментарий. Будем попровать.

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

Код AS3:

public class BattleCharacterModel  // Модель для общих свойств и методов

        {

                internal var character:Character;

 

                public function BattleCharacterModel (newCharacter: Character) 

                {

character = newCharacter;

                }

}

 

public class BattleCharacterModelHero extends BattleCharacterModel // Класс для модели героя

        {

                public function BattleCharacterModelHero (newCharacter: CharacterHero) 

                {

                        super(newCharacter);

                }

Беда в том, что после создания экземпляров при попытке обратиться к свойствам, установленным для CharacterHero, через _heroModel.character.'имя свойства', получаю ошибку. Мне это кажется странным, т.к. установленная типизация исключает записи в переменную character класса BattleCharacterModelHero значения иного типа, кроме CharacterHero.

Как итог пока нашёл решение с заданием переменных Character непосредственно в классах-наследниках, но что-то меня в этом варианте смущает. Пока правда, не понимаю, что контретно. Вот так получилось:

Код AS3:

public class BattleCharacterModel  // Модель для общих свойств и методов

        {

                public function BattleCharacterModel () 

                {

                }

}

 

public class BattleCharacterModelHero extends BattleCharacterModel // Класс для модели героя

        {

                internal var character: CharacterHero;                

                public function BattleCharacterModelHero (newCharacter: CharacterHero) 

                {

                        character = newCharacter;

                }

Код AS3:

internal var character:Character;

Ну так тип свойства то — Character. У него нет свойств CharacterHero, так?
Дело в том что компилятор то не знает, что ты запихал в свойство типа Характер ссылку на экземпляр ХарактерХеров. Он не отслеживает рантайм, он не телепат. Он видит что тип такой-то и у него нет свойства такого-то, вот и вся ошибка. Почему я не очень люблю наследование — постоянно надо кастовать, то есть объяснять компилятору, что дружить мы будем только с ХарактерХеров:

Код AS3:

(_heroModel.character as CharacterHero).'имя свойства'

(кажется, мы это уже проходили на Гендерах? Что ты можешь выдать ХарактерХеро за Характер, так как у него есть ВСЁ из Характера, но не наоборот)

Добавлено через 13 минут
Похоже, ты сейчас подходишь к наследованию слегка.. механически. Типа, "есть общие свойства — а соберу ка я их в суперкласс". Но не всё так просто. Надо подумать, зачем ты их собираешь в суперкласс, как это пригодится тебе в жизни (кроме очевидного неповторения строчек кода). Как они потом жить будут. Будешь ли ты использовать наследников вместо супера. А не наоборот. Наследование не дает тебе преимущества иметь переменную типа супер, запихать туда любого наследника и потом работать с ней так, как будто она наследник. Если у тебя переменная типа Характер, и в нее могут быть засунуты и Херо и Енеми, то беспрепятственно ты можешь обращаться только к тем свойствам, которые унаследованы от Характер. Иначе вообще было бы непонятно и бессмысленно называть это типизацией, если бы ты мог обращаться к типу Характер за свойствами, которых у него нет. Тебе придется создать переменную НУЖНОГО типа-наследника и перекастовать туда (то есть с проверкой) ссылку из переменной супертипа Характер. Чтобы знать ТОЧНО, что это наследник и стало быть у него есть эти свойства наследника.

Цитата:

Сообщение от Wolsh (Сообщение 1203141)

(кажется, мы это уже проходили на Гендерах? Что ты можешь выдать ХарактерХеро за Характер, так как у него есть ВСЁ из Характера, но не наоборот)

Да, так и есть. :) Повторение - мать (такая-то) учения. А вариант иметь свойства с идентичными именами в классах-наследниках, это нормальное решение?

Цитата:

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

Похоже. В моём понимании, неповторение строчек кода - уже большое дело. Ведь это ещё и вопрос внесения изменений. Если наследники имеют общий метод в сеперклассе, я могу поменять там его и быть 100% уверенным, что он поменялся у всех, и одинаково. Плюс в моём конкретном случае я вижу необходимость несколько различной обработки одних и тех же вводных для Hero и Enemy. Это тоже толсто намекает на перспективу засылать вводные в метод супера и переопределять их в наследниках. Мне кажется, достаточные основания.

Цитата:

Если наследники имеют общий метод в сеперклассе, я могу поменять там его и быть 100% уверенным, что он поменялся у всех, и одинаково.

Не можешь, потому что наследники могли переопределить для себя этот метод и тогда не имеет значения, что ты там исправил в суперклассе.

Цитата:

Это тоже толсто намекает на перспективу засылать вводные в метод супера и переопределять их в наследниках.

У тебя одно предложение опровергает другое ;)
Переопределяй суперметоды, если это возможно. Как бы в этом смысл наследования, а не в том чтобы накидать в наследник кучу новых методов — по сути создав новый класс с ДРУГИМ интерфейсом.
Если невозможно, то придется кастовать.

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

Но мысль на счёт накидывания методов в наследник я уловил, спасибо.