1

現在、私は単純化された標準的な戦略パターンの実装を持っています:

public interface IStrategy
{
    IList<Dog> GetDogs();

}

public class DogStrategy: IStrategy
{
    public IList<Dog> GetDogs()
    {
       return new List<Dog>();
    }
}

戦略を使用するクラスもあります。

public class DogCollection
{
    private IStrategy strategy;
    public IStrategy Strategy
    {
        get { return strategy; }
        set
        {
            if (strategy == null || value.GetType() != strategy.GetType())
            {
                strategy = value;
                //do stuff
            }
        }
  }

問題: パターンを 2 か所に実装してわかったことは、インターフェイスが少し増殖し始めていることです。これは扱いやすく柔軟性がありますが、ファイルが多すぎると同僚が動揺することはわかっています。彼らは設計パターンが好きではありません。また、戦略に共通のロジックを使用する必要があるため、コレクションには継承元の抽象クラスが必要です。

これらのインターフェイスをすべて使用する代わりに、追加のロジックを含むジェネリック コレクションから DogCollection を継承させることを考えていました。

public class DogCollection : GenericCollection<Dog>

IStrategy プロパティではなく、Loader プロパティを使用できます。次に、両方の戦略パターンのさまざまなファイルを削除できます。

public abstract class GenericCollection<T> 
{
    private Func<IList<T>> loader;
    public Func<IList<T>> Loader
    {
        get { return loader; }
        set 
        {
            loader = value; 
            //do stuff
        }
    }
}

さまざまな条件で具体的な戦略の実装を開始し、DogCollection で戦略を設定して戦略を設定する代わりに、さまざまな Dog を取得して Loader プロパティを割り当てるルーチンを含む静的クラスを作成するだけです。次に、loader プロパティを使用して、要求されたときにリストを返すことができます。

どちらが優先され、その理由は何ですか?

4

1 に答える 1

2

これはまだ戦略パターンです。

設計パターンは、使用するプログラミング言語の欠点を克服するためによく使用されることに注意してください。

C# では、デリゲート型を使用することにより、関数はほぼいわゆるファースト クラスの市民であり、実際には戦略をインターフェイスとクラスにラップする必要はありません。

効果は基本的に同じであり、Func<>デリゲートを使用する 2 番目のアプローチをお勧めします。つまり、コード、インターフェイス、クラス、ファイル、および混乱が少なくなります。

于 2013-10-24T12:08:30.320 に答える