Вопрос по проектированию

[Wolsh]

Но у тебя всё равно напутано, ибо именительный - это 0, а у тебя в тексте стоит *$n1

Потому что в моем тексте нет именительного. "окажется дочкой Маши Шараповой" это Родительный.

Почему ты так считаешь?

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

[Appleman]

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

Потому что в моем тексте нет именительного. "окажется дочкой Маши Шараповой" это Родительный.

И всё равно есть ошибка, т.к. i перебирается плоть до значения 6, а значит, включая 0 для именительного падежа, один должен быть лишний, т.к. падежей всего шесть

Я с позволения задам ещё пару вопросов по проектированию. К сожалению, пока никакого чутья на это дело нет, и перед реализацией каждой даже самой проходной задачи приходится долго тупить на предмет того, в какой класс разместить код или вообще создавать новый класс и т.п. Рекомендации уважаемых Nooob и Wolsh - ощутимо помогают (хоть отчасти противоречат друг другу), то пока тоже не смогли успокоить мою душу.

Уже кратко спрашивал, теперь постараюсь подробнее сформулировать суть моего вопроса и альтернатив. Продумывая игровых персонажей и их механики, вывел 3 группы: npc, ключевые npc и сам игрок. Количество свойств увеличивается от npc до игрока. Когда дошла очередь до проектирования классов, я нарисовал табличку, где в столбцы поставил эти группы, а в строки - свойства. А дальше ставил на пересечении галочки, используется ли данное свойство или нет. По итогу получился такой расклад: совсем небольшое количество базовых свойств попали во все три группы (имя, ID, пол и т.п.), некоторое количество оказалось уникальным для персонажа игрока, ещё небольшая группа оказалась общей для npc и ключевых npc, наконец, пачка уникальных свойств только для ключевых npc. Итого 4 "профиля вхождения". Они определили вот такую структуру наследования классов:

Charactrer - базовые свойства, общие для всех персонажей
          |   |
          |    - Character_hero - главный герой
          |
           - Character_npc - общие свойства для неписей и ключевых неписей
                      |
                       - Character_npc_key - уникальные свойства для ключевых неписей

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

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

Что остаётся? Первое, оставить как есть сейчас, для расчётов игровой механики писать классы с абстрактными методами для каждого из подклассов персонажей, т.е. воспользоваться прелестями полиморфизма (или зря я столько книжек прочитал!). Но смущает, что во-первых, дерево наследование кривое получается (вопрос, повлияет ли этот факт на работу абстрактных методов и вообще, насколько подобный перекос допустим), плюс много писанины - по 3 подкласса на каждый класс с расчётами. При условии, что ни в близком, ни в отдалённом времени я не планирую вводить другие группы персонажей (для которых было бы как раз удобно добавить отдельных потомков), всё это выглядит перебором и необоснованным усложнением.

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

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

Буду признателен за развёрнутый ответ.