空派生クラスVs型プロパティ

Question

以下の2つの例の長所と短所を特定することができません。

例1（タイププロパティ）：

public abstract class Animal : /* all relevant interfaces*/ 
{ 
    /* 
    All necessary implementations 
    */ 
} 

Public class Dog : Animal 
{ 
    Public string Name {get; set;} 
    Public Breed Type {get; set;} 

    /* 
    All necessary implementations 
    */ 
} 

Public Type Breed 
{ 
    Bulldog, 
    Chihuahua, 
    Labrador, 
    /* 
    So on…… 
    This can grow without limitation, 
    you dno't know how much it will grow into, or 
    what breed you will have tomorrow e.g BulldogChihuahuaCross, 
    or BulldogLabradorCross. 
    */ 
} 

例2（空の派生クラス）：

public abstract class Animal : /* all relevant interfaces*/ 
{ 
    /* 
    All necessary implementations 
    */ 
} 

Public class Dog : Animal 
{ 
    Public string Name {get; set;} 

    /* 
    All necessary implementations 
    */ 
} 

Public class Bulldog : Dog 
{ 
    /* Empty Class */ 
} 

Public class Chihuahua: Dog 
{ 
    /* Empty Class */ 
} 

Public class Labrador: Dog 
{ 
    /* Empty Class */ 
} 

理想的には私は最高のデザインと高い重どの知っていただきたいと思います編集：

例1では、Dogのインスタンスが作成され、その型がプロパティとして割り当てられます。例2では、​​その特定の型のインスタンスが作成されます。

私はいくつかのindepth引数、スケーラビリティ、maintainablity、1000種類の品種がある場合はCPUのコスト、実行クエリのコストなどを探しています。

Answer 1

スペクトルには2つの極端なものがあります。一方では、単なる情報であり、列挙されたインスタンスへのテキスト、数値、または参照として扱われる一連のものがあります。たとえば、犬のサロンアプリケーションでは、ペットの名前、色、品種などを識別目的のテキストとして記録する場合があります。スペクトルの反対側には、異なるプロパティ、操作、またはメソッドを持つ必要のある一連のものがあります。例えば、ビデオゲームでは、吠えたときに犬の品種ごとに異なる音を出すことができます。

デザイナーとして決定しなければならない決定は、「談話の領域」と特定のアプリケーションのショートカットをいつどの程度正確に反映させるかです。談話の領域では、各品種に独特の特性がありますが、犬のサロンアプリケーションの目的では、気にしません。その場合、詳細をデザインすることができ、将来必要としないことを希望することができます。

問題は、誰かが間違った決定をするスペクトルの真ん中にあります。大規模なエンタープライズ・システムでは、継承階層を1つまたは複数のデータベース列の値として明示的にエンコードされた型に圧縮していました。これは恐ろしいことでした。なぜなら、エンコードされたすべてのタイプに対して他のどの列が有効かを知ることがプログラマーの問題になったからです。このシステムには、時間の経過と共に進化したビジネスルールを実装するためのスイッチ文がすべて、非常に複雑なものになっていました。システムには多くのバグがありました。

そのため、スペクトルの途中で、物事が明確にカットされていないところでは、私は多くのクラスの面で間違っていました。その理由は、ドメインを正確に反映することで、要件が満たされているかどうかを簡単に伝えることができ、コードをより直観的に維持することができます（DDDと仮定します）。ドメインを反映する鍵は、物事を正確に表現することです。たとえば、「Fido」はDogセットとAnimalスーパーセットのメンバーです。 "シルベスター"は、キャットセットとアニマルスーパーセットのメンバーです。これは人々が理解しやすく、各クラスは外部から隠された異なる実装を持つことができます。文字列、整数、または列挙型のリテラル参照として明示的にコード化された型の解釈を開始したら、switch文が必要です。多くのオブジェクト指向言語はすべてのことからあなたを救うことができますが、タイプの完全なリストを含むファクトリを作成する必要があります。ランタイムオーバーヘッドは無視できます（特に、一定時間で実行するようにファクトリを実装する場合）。リレーショナルデータベース内の値に型をマップして、それらを照会してレポートすることができます。また、あなたが指摘しているように、ジェネリック医薬品を利用できるかもしれません。

犬のサロンアプリケーションの場合のように、クラスが常に空であることが分かっている場合は、クラスを気にしないでください。異なるプロパティ、操作、およびメソッドを持つことがわかっている場合や、わからない場合は、クラスを使用してください。

Answer 2

最初の方法では、どの品種が犬であるかを判断できますが、2番目の方法ではサブクラスの特定の実装を行うことができます。

犬種別ごとに異なるメソッドやプロパティを持つオブジェクトが必要な場合は、派生クラスを参照してください。それ以外の場合は、typeプロパティと単一クラスを持つ方が簡単です。

Answer 3

これは私の2セントです：何かへの高速アクセスを探しているなら、それを連想配列にします。どちらの実装でも、同じ速度でアクセスできるハッシュコード（オブジェクトアドレス）を使用します。サブクラス化は、機能を追加する場合にのみ意味があります（基本的に）。分類子から型を取得することは、列挙から型を取得することと変わりありません。巧妙なクエリが必要な場合は、巧妙な連想配列を作成します。