私は、このシステムを構築してきたこの 2 か月の間に、この問題に頻繁に直面しました。シナリオは次のとおりです。本質的には他のオブジェクトのリストですが、その性質に固有の他のプロパティを持つこの種のオブジェクトがあります。例えば：
Tests:
Testオブジェクトが含まれていますDefaultTimeoutsDefaultNumberOfTriesこのクラスのサブクラスを作成List<Test>する必要がありますか、それとも から継承してObject、単にリストを他のフィールドの横にあるプロパティとして保持する必要がありますか?
これは少し主観的であり、個人的な好みがここで役割を果たす可能性があることは承知していますが、これについてのあなたの意見を心から知りたいです.
ここでのほとんどの回答とは対照的に、ほとんどの場合、リストからサブクラス化しません。クラスから継承して機能を再利用すると、通常、後で問題が発生することがわかりました。
私は通常、リストへの参照を返す List (または IList) 型のプロパティを持っています。通常、ここでは get プロパティのみが必要です。.AsReadOnly() を使用してリストの読み取り専用バージョンを返すことを選択するか、リストを IEnumerable として公開するだけで、リストへのアクセスを制御できます。
テストをリストにしたい場合は、通常 IList を実装し、IList の実際の実装のために内部 List フィールドを呼び出します。これは少し手間がかかり、維持するコードが増えますが、実装のためだけに List を継承するよりも維持しやすいことがわかりました。
List<T> のサブクラス。List ジェネリックをプロパティとして持っている場合、それはサブクラスほどカプセル化されていません。
List<T> のように見え、List<T> のように聞こえる場合は、おそらく List<T> です。
私はこれを TestCollection と呼んでいます。
それが文字通りすべてListを実行し、すべての関数が正しい結果をもたらす直感的な方法でオブジェクトにList作用する場合、私の意見では、サブクラス化する必要があります。TestsList<Test>
List<Test>そうしないと、インスタンス内の変数で同じ名前のメソッドを呼び出すだけの大量のメソッドを持つクラスができてしまいます。List<Test>それは、クラス自体の不完全な拡張にすぎません。
一般に、継承は「is-a」関係にマップされます。あなたのコンテナはリストですが、他のいくつかのものがあるので、Listから継承し、追加のプロパティをサブクラスに追加します。
もっと何かが必要だったので、あなたが持っているのは単純な「テストのリスト」ではないと思います。TestSuiteそれを呼び出して、リストをプロパティとして作成することをお勧めします。Has-aは、継承に比べて保守がはるかに簡単です。
一般的に、私はList.
答えを読むと、重要な質問は、オブジェクトが実際にリストである長さはどれくらいですか? したがって、継承の危険と構成の透明性の欠如との間の適切な妥協点はList<Test>、プライベート バックエンドとして を持ち、使用されるメソッドのみを公開することです。
あなたの例では、「クラス テストには多くのテスト オブジェクトが含まれています」と言いましたが、「クラス テストはテスト オブジェクトのコレクションです」ではありません。IMO このシナリオでは、このクラスに List のようなインターフェイスが必要でない限り、List をサブクラス化する必要はありません。
ただし、答えは実際には Tests クラスのコンテキストに依存します。リストのように動作し、オブジェクトのリストが期待されるコンテキストで使用される場合は、リストから継承します。
継承は構成よりも維持するのが難しいことに注意してください。
また、Tests の名前を TestCollection (List をサブクラス化する場合)、または TestUnit のような名前 (Test クラスのリストを含む場合) に変更します。
「継承よりも構成を優先する」というのは、常に良い経験則です。このクラスを使用するメソッドは、追加したものだけでなくすべての List メソッドを使用していますか、それとも追加したものだけですか?