私のプロジェクトでは、さまざまな種類のオブジェクトにオブジェクト プールを使用したいと考えています。動作は似ていますが、プール サイズは異なります。
作成したオブジェクトに適用するプールとインターフェイスのジェネリック クラスを作成する必要がありますか?それとも、共通のロジックを使用して抽象プール クラスを作成し、それを使用するすべての異なるクラスに対して特定のサブクラスを作成する必要がありますか?
私のプロジェクトでは、さまざまな種類のオブジェクトにオブジェクト プールを使用したいと考えています。動作は似ていますが、プール サイズは異なります。
作成したオブジェクトに適用するプールとインターフェイスのジェネリック クラスを作成する必要がありますか?それとも、共通のロジックを使用して抽象プール クラスを作成し、それを使用するすべての異なるクラスに対して特定のサブクラスを作成する必要がありますか?
両方の機能を持つことができます。つまり、抽象ジェネリック クラスを作成できます。ジェネリック クラスによって実装され、ファクトリ メソッド/クラスの背後にある特定の型に対してインスタンス化されたジェネリック インターフェイスを使用したいと思います。抽象クラスは、派生クラスの作成を強制するため、面倒になります。私が念頭に置いている使用例は次のようなものです
IPool<MyClass> = PoolFactory.Get<MyClass>(5); // 5 being pool size
IPool<IFoo> = PoolFactory.Get<FooImpl>(5);
IPool<IBar> = PoolFactory.Get(5, () => new BarImpl("some argument")); // instance creation with factory method
ジェネリック クラスから継承することで、特殊化の余地が残される可能性があることに注意してください。通常は、複雑なインスタンスの作成が必要になります (もちろん、プール実装にファクトリ インターフェイスまたはファクトリ デリゲートを提供することでモデル化できます)。
Stack<T>
これは、オブジェクトベースのクラスよりもジェネリックを好む理由Stack
と、オブジェクトベースのクラスの問題を解決するためにジェネリックが導入された理由の典型的な例です。これは、MSDNのMSDNで説明されています。
2番目のオプションを使用する場合は、作成するすべてのオブジェクトプールにを導入する必要がnew concrete class
あります。これは、保守と開発future
が面倒です。したがって、ジェネリッククラスを作成する最初のオプションを選択してください。そうです、別の回答で説明されているように、この最初のオプションでデザインパターンの利点を利用することもできます。Pool<T>
Factory
実際、ここにサンプルの汎用ObjectPool<T>
実装があります。
これがジェネリック型の典型的なシナリオです。だから私はジェネリックプールを提唱します。
ジェネリックスは、他のクラスが具体的な型を知らずにジェネリックスへの参照を使用する場合にのみ問題を引き起こします。その場合、ジェネリックプールクラスによって実装される非ジェネリックインターフェイスを作成できます。