アドベンチャーゲームのクラスデザイン

Question

私は現在、小さな冒険に取り組んでおり、アイテムとnpcインスタンスのために最高のクラスデザインが何かを知りたいと思います。

私は、継承（ItemInstance - > EquipmentInstance）を使用した非常に基本的なクラスデザインから始めましたが、後の設計選択のために柔軟性を持たせたいので、うまく機能しません。有能なNPC（例えば小動物）。

だから、私は1つのアイテムのインスタンスを保持することができ、基本クラス、NPCのインスタンスまたはその両方を作成するためのアイデアを思い付いた：

public class Instance { 

    public int instanceId; 

    public ItemInstance itemInstance; 
    public NPCInstance npcInstance; 
} 

itemInstanceは数量、武器や装備のため、そしてもちろんのフィールドを保持することができ、この方法では、 npcInstanceは、現在のヘルス、マナ、そしてすべてのものを保持します。

しかし、これが良い解決策であるかどうか、またはそれが欠点につながるかどうかはわかりません。もちろん私は選択肢にもオープンしています。

ありがとうございます！

Answer 1

Minecraftのようなエンティティベースのクラスはかなりうまくいくようです。次に、プロパティを持つ基本クラスItem装備可能

Answer 2

あなたのクラスデザインで未来を予知するのは良いことです。しかし、私はアジャイル開発を読むことをお勧めします。特に、次の要件のコードのみで、すべての要件のリファクタリングが必要です。開発の初期段階で最適なクラスデザインがどのように見えるかは、事前に伝えることはほとんど不可能です。

シンプルにすることは、実装しようとしている現実があなたのクラスに反映されるようにすることも意味します。あなたのケースでは、アイテムはNPCの所有物であると言いたいと思います。なぜなら、アイテムは（小さな動物の場合には）アイテムを持ち運ぶからです。あなたのシステムのすべてのクラスが共通の振る舞いを持つことを正当化すると考えられる場合、NPCとアイテムの両方がインスタンスを継承することがあります。 intプロパティを共有するためにインスタンスから継承することは、過度の攻撃のようです。

良いクラスデザインはSOLIDの原則に従います。

Answer 3

この質問はここでは多少話題にはなりませんが、エンティティの継承は通常デザインの匂いであることを指摘したいと思います。

継承は基本的に、類似のの動作を持つクラス間の関係を構築することに関するものです。これは、エンティティとオブジェクトの違いについて考える価値があります。

• エンティティは通常、バック、アプリケーションの機能要件（ユーザーに関する情報を格納し、例えば「ユーザー」エンティティ）に関連する何かの状態の表現です。
  エンティティは通常、混合状態と振る舞いが、SRP（Single Responsibility Principle）に違反する肥大化した柔軟性のないクラスにつながり、適切に管理するために複雑な「if/else」コードを必要とする可能性があるため、

• オブジェクトは、通常、動作をカプセル化するクラスです。エンティティまたは他のオブジェクトと相互作用してもしなくてもよい。オブジェクトには何らかの内部状態が存在することがよくありますが、これは動作に関連する状態であり、ユーザが考えるものではありません（たとえば、元に戻す/やり直しのアクションのリスト、isInitialisedフラグ、または管理されていないリソース）。

オブジェクトとエンティティを分けることを検討してください。この方法ではるかに少ないエンティティしか必要としないことに気付くかもしれません。たとえば、Sword、Gun、Axeなどの複数のクラスを作成する代わりに、と呼ばれる単一のエンティティで終了することがあります。"Sword", "Gun", "Axe"はデータで表されます。 （エンティティモデルは、オブジェクト指向モデリングに非常に異なった考え方であり、エンティティのモデリングのために、それは代わりに、リレーショナル・データの観点から考えるのに役立つかもしれません）

通常の継承は、類似し行動を持つクラスを作成する方法についてです。多くの場合、うまく設計されたビヘイビアクラスはその目的にちなんで名付けられます。例えば、Gunはエンティティのように聞こえますが、GunDamageCalculatorは何か役に立つかもしれない何かに似ていて、AxeDamageCalculatorまたはCandlestickDamageCalculatorなど

要約すると - 継承はあるためにアナロジーは、IS-関係はない属性行動に適用されます。ほとんどのソフトウェアの現実は、CatをAnimalまたはCarの形でVehicleの形で記述することはしばしば役に立ちません。多くの場合、エンティティ "基本クラス"はかなり無駄になり、実際にはあなたを助けませんあなたのプログラムを書いてください。