アーキテクチャ（リアルタイム戦略ゲームのNPC）の多重継承に代わるものはありますか？

コーディングは実際にはそれほど難しくありません。難しい部分は、理にかなっており、読みやすく、理解可能なコードを書くことです。だから、私はより良い開発者を獲得し、強固なアーキテクチャを作りたいと思っています。

それで、私はビデオゲームでNPCのアーキテクチャを作成したいと思います。これは、Starcraft、Age of Empires、Command＆Conquersなどのようなリアルタイム戦略ゲームです。したがって、さまざまな種類のNPCがあります。A NPCは、これらの多くの能力（メソッド）に1を持つことができますBuild()、Farm()とAttack()。

例：
労働者がすることができますBuild()し、Farm()
戦士缶Attack()
市民缶Build()、Farm()とAttack()
漁師ができるFarm()とAttack()

これまでのところすべてが明確であることを願っています。

だから今、私は私のNPCタイプとその能力を持っています。しかし、技術的/プログラム的な側面を見てみましょう。
さまざまな種類のNPCに適したプログラムアーキテクチャは何でしょうか。

さて、基本クラスを持つことができました。実際、これはDRYの原則を守る良い方法だと思います。WalkTo(x,y)すべてのNPCが移動できるため、基本クラスのようなメソッドを持つことができます。しかし今、本当の問題に取り掛かりましょう。自分の能力をどこで実装しますか？（覚えておいてください：Build()、Farm()およびAttack()）

能力は同じロジックで構成されるため、各NPC（Worker、Warrior、..）にそれらを実装することは、DRYの原則に迷惑をかける/破るでしょう。

さて、基本クラス内に能力を実装できました。NPCは、能力Xを使用することができる場合、これは検証というロジックのいくつかの種類が必要になりIsBuilder、CanBuild、..私は私が表現したいものを明確だと思います。
しかし、私はこの考えにあまり気分がよくありません。これは、機能が多すぎる肥大化した基本クラスのように聞こえます。

プログラミング言語としてC＃を使用しています。したがって、ここでは多重継承はオプションではありません。手段：のような追加の基本クラスがあるFisherman : Farmer, Attackerと機能しません。

構成とインターフェイスの継承は、従来の多重継承の通常の代替手段です。

上記で説明した「can」という単語で始まるものはすべて、、ICanBuildまたはなどのインターフェイスで表すことができる機能ですICanFarm。これらのインターフェースは、必要な数だけ継承できます。

public class Worker: ICanBuild, ICanFarm
{
    #region ICanBuild Implementation
    // Build
    #endregion

    #region ICanFarm Implementation
    // Farm
    #endregion
}

クラスのコンストラクターを介して、「ジェネリック」なビルドおよびファーミングオブジェクトを渡すことができます。それが作曲の出番です。

他のポスターが述べているように、コンポーネントアーキテクチャがこの問題の解決策になる可能性があります。

class component // Some generic base component structure
{
  void update() {} // With an empty update function
} 

この場合、更新機能を拡張して、NPCに必要な機能を実装します。

class build : component
{
  override void update()
  { 
    // Check if the right object is selected, resources, etc
  }
}

コンポーネントコンテナを繰り返して各コンポーネントを更新すると、各コンポーネントの特定の機能を適用できます。

class npc
{
  void update()
  {
    foreach(component c in components)
      c.update();
  }

  list<component> components;
}

オブジェクトの各タイプが必要なため、何らかの形のファクトリパターンを使用して、必要な個々のタイプを作成できます。

npc worker;
worker.add_component<build>();
worker.add_component<walk>();
worker.add_component<attack>();

コンポーネントがますます複雑になるにつれて、常に問題に直面しています。コンポーネントの複雑さを低く抑える（1つの責任）ことで、その問題を軽減できます。

このようにインターフェースを定義する場合ICanBuild、ゲームシステムはタイプごとにすべてのNPCを検査する必要があります。これは通常、OOPで顔をしかめます。例：if (npc is ICanBuild)。

次の方法をお勧めします。

interface INPC
{
    bool CanBuild { get; }
    void Build(...);
    bool CanFarm { get; }
    void Farm(...);
    ... etc.
}

次に：

class Worker : INPC
{
    private readonly IBuildStrategy buildStrategy;
    public Worker(IBuildStrategy buildStrategy)
    {
        this.buildStrategy = buildStrategy;
    }

    public bool CanBuild { get { return true; } }
    public void Build(...)
    {
        this.buildStrategy.Build(...);
    }
}

...またはもちろん、さまざまなタイプのNPCなどを定義するための流fluentなインターフェイスの形式のドメイン固有言語など、さまざまな動作を組み合わせてNPCタイプを構築する、さまざまなアーキテクチャを使用できます。

var workerType = NPC.Builder
    .Builds(new WorkerBuildBehavior())
    .Farms(new WorkerFarmBehavior())
    .Build();

var workerFactory = new NPCFactory(workerType);

var worker = workerFactory.Build();

NPCビルダーはDefaultWalkBehavior、飛行しても歩行できないNPCの場合にオーバーライドされる可能性のあるを実装できます。

私はすべての能力を、能力から継承する別々のクラスに入れました。次に、ユニットタイプクラスには、能力のリストと攻撃、防御、最大ヘルスなどのその他のものがあります。また、現在のヘルス、場所などを持ち、メンバー変数としてユニットタイプを持つユニットクラスがあります。

ハードコーディングするのではなく、設定ファイルまたはデータベースですべてのユニットタイプを定義します。

次に、レベルデザイナーはゲームを再コンパイルせずにユニットタイプの能力と統計を簡単に調整できます。また、ゲームのmodを作成することもできます。