Могут ли быть соответствующими интерфейсы, представляющие каждый атрибут класса игрока? Есть ли проблемы с этим?Интерфейсы для атрибутов плеера
Как атрибуты добавляются в модель, так и интерфейсы, приводящие к длинной декларации.
public class Player : INamed, IEnergy, IInventory, IMana, ...
{
public string Name { get; set; }
public int Energy { get; set; }
public int Mana { get; set; }
public Inventory Backpack { get; }
...
}
мне, что бы сказать мне, что не все игроки имеют имя, энергию и т.д. Для основной игры, все блоки, как правило, имеют какие-то название и серию хитов, обозначающую, как много вреда может взять блок.
Если все единицы в игре имеет схожие свойства, но различных значения (может быть, священник может выдержать меньше повреждений, чем солдаты, но может двигаться быстрее, так как он не имеет брони), вы можете определить интерфейс который определяет поведение ваших юнитов, таким образом, вы могли бы иметь что-то вроде этого:
public interface IBaseUnit
{
int HitPoints
..
}
Затем каждый конкретный блок будет иметь свою собственную реализацию. При этом я предполагаю, что единицы будут действовать аналогичным образом в большинстве случаев, поэтому было бы более эффективно использовать абстрактный класс вместо интерфейса в верхней части вашей иерархии.
@ DaneshM .: Пожалуйста, предоставьте дополнительную информацию. Какие свойства распределяются между объектами, а какие нет? – npinti
@DaneshM: Я бы предположил, что те, у кого есть инвентарь, будут принадлежать определенному классу единиц, то же самое относится к тем, у кого есть мана. – npinti
@DaneshM. Ваше понимание класса неверно. Класс Player будет иметь определенные свойства, поэтому все объекты Player также будут иметь эти свойства, так как, хорошо, они * являются * Player. Это похоже на то, что вы создадите классную собаку, и тогда он захочет, чтобы некоторые из них имели возраст, а некоторые из них не были. Это просто ложь. – Eminem
На мой взгляд, вам нужна иерархия классов, а не куча интерфейсов. Вместо того, чтобы создавать большой пул «свойств», которые могут иметь разные символы, вам будет лучше посоветовать моделировать некоторую иерархию с некоторыми базовыми абстрактными классами, от которых наследуются конкретные единицы.
Основная идея:
abstract class Character
{
String name
int hitpoints;
IList<Item> inventory;
}
abstract class Spellcaster : Character
{
int manapoints;
IList<Spell> knownSpells;
}
class Mage : Spellcaster
{
// Mage specific stuff
}
class Necromancer : Spellcaster
{
// Necromancer specific stuff
}
И так далее. Очевидно, что классы, которые вы моделируете, будут зависеть от того, какую игру вы делаете.
Я не понимаю. Name, Energy, Mana и т. Д. Являются _properties_ игрока, поэтому они должны быть свойствами внутри класса. Зачем вам создавать интерфейс для каждого из них? – Eminem
№ Свойства, представляющие каждый атрибут игрока, были бы уместными. Если вы берете игрока, звучит ли уместно, что игрок является «Mana» или что игрок является «энергией»? Вы когда-нибудь использовали бы один из этих интерфейсов? Это даст вам преимущество программирования? Если нет, ваш подход == дополнительный шум. – spender
Я думаю, вы должны прочитать [this] (https://msdn.microsoft.com/en-us/library/3b5b8ezk%28v=vs.90%29.aspx) и [this] (https: // msdn. microsoft.com/en-us/library/bzwdh01d%28v=vs.71%29.aspx). – Eminem