Дизайн класса с полиморфизмом и наследованием - PullRequest
0 голосов
/ 07 августа 2011

В настоящее время у меня есть следующее:

public abstract class CharacterClass
    {

        public abstract Attribute FirstAttributeBonus { get; }
        public abstract Attribute SecondAttributeBonus { get; }

        protected Attribute[] attributeBonuses; //2 attribute bonuses, which add 10 to the attributes stored in the array.
        protected SKill[] majorSkills; //Major skills for class begin at 30.
        protected Skill[] minorSkills; //Minor skills for class begin at 15.

        protected IDictionary<int, Character> characterList; //List of characters who apply to this class specifically.

        public CharacterClass()
        {

        }

    }

Имея в виду, что любой класс, который я создаю, будет наследовать от этой базы, а также наследовать поля классов.Например, один класс может быть Воином;другой может быть Battlemage и т. д.

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

Редактировать:

Я забыл упомянуть, что все производные будут синглетонами, и я изменяю имя класса на«CharacterClass», чтобы избежать путаницы.

Ответы [ 4 ]

2 голосов
/ 07 августа 2011

Я предполагаю, что вы имеете в виду не какой бы * класс 1002 *, а скорее все классы игровых объектов ?В таком случае это может быть хорошим дизайном, если all игровому объекту действительно нужны эти атрибуты.

Роль абстрактного базового класса состоит в том, чтобы собрать общий код, чтобы избавиться от повторений вподклассы.Если все подклассы игровых объектов нуждаются в этих полях, то правильно поместить их в базовый класс.Если разные подклассы игровых объектов инициализируют их различными значениями, то правильно отложить инициализацию для подклассов.

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

Я предполагаю, что вы имеете в виду пример конструктора?Измените свой существующий

public CharacterClass()
{
}

на что-то вроде

public CharacterClass(Attribute[] attributeBonuses, 
  SKill[] majorSkills, Skill[] minorSkills)
{
  if(attributeBonuses == null || majorSkills == null || minorSkills == null)
    throw new ArgumentException("Null values are not allowed");

  this.attributeBonuses = attributeBonuses;
  this.majorSkills = majorSkills;
  this.minorSkills = minorSkills;
}
1 голос
/ 07 августа 2011

Вам совершенно необходимо взять книгу под названием Head Start Design Pattern. Вам не нужно читать всю книгу целиком: в ее первой главе описывается шаблон проектирования, который вы хотите реализовать.

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

Найдите 20 минут, чтобы прочитать первую главу: http://oreilly.com/catalog/9780596007126/preview

0 голосов
/ 07 августа 2011

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

Тем не менее, часть, которая мне особенно не нравится, это IDictionary<int, Character> characterList;.

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

0 голосов
/ 07 августа 2011

Я думаю, что это пахнет.Этот кодовый запах даже имеет имя: Бог - класс .

ИМО, не очень хорошая идея создать один класс "матери" (или бога), где все другие классы наследуютfrom.

Я вижу в вашем базовом классе некоторые свойства, такие как MajorSkills.Я вижу, что у вас будет класс "BattleImage", который вы унаследуете от этого базового класса, но я не думаю, что у изображения есть навыков .Я бы создал более конкретные базовые классы и наследовал бы только от этих базовых классов, если существует отношение Is A .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...