ソートにFactoryが不十分なのはなぜですか？

Question

私はフォーラムでこれを発見し、それをうまく説明しているように見える：

戦略は、あなたがアルゴリズムのクライアントを壊すことなく、お使いのソフトウェアに新しい（あなたのケースの並べ替え中）のアルゴリズムを追加することができますを目的としたパターンです。 。クライアントを壊すことなく新しいアルゴリズムを追加する必要がある場合、これは設計の複雑さへの投資です。ファクトリはストラテジを補完するパターンです。アルゴリズム実装のクライアントは、使用している実装（ソフトウェアクラスの面で）を具体的に知ってはいけないためです。ファクトリは、アルゴリズムの具体的な実装をインスタンス化して、クライアントが詳細を知らずにそれらを使用できるようにします。

は、しかし、私たちはちょうどソート文字列を返すために、工場に依頼しないでSortStrategtyInterface.Shouldの必要性を理解することはできませんメートル。

また、上記のいずれかの問題が正しい場合は、これを呼び出すコードを共有できますか？ SortstrategyInterfaceを削除した場合の例もありますが、どのような欠点がありますか？

Answer 1

インターフェイスは必ずしも「必要」ではありませんが、クライアントとさまざまなソートアルゴリズムとの間の契約を保証するのは難しいことです。この契約では、メソッドgetSortString（）がファクトリから返されるどの戦略にも存在することをクライアントに保証するだけです。コードのphp5から次のようになります。

$sorting_obj = SortStrategyFactory::getSorterBy("demand"); 
if (! $sorting_obj instanceof SortStrategyInterface) { 
    throw new \exception('contract failed, the sorting algorithm must implement the SortStrategyInterface'); 
} 
$sorting_obj->getSortString(); 

# or maybe: 
try { 
    $sorting_obj = (SortStrategyInterface)SortStrategyFactory::getSorterBy("date"); 
} catch (\exception $e) { 
    # ... 
} 
$sorting_obj->getSortString(); 

インタフェースは「本当に」必要なことは決してありませんが、その使用は確かに本当の欠点と利点のトンを持っています。クライアントと実装間の契約を維持することで、長期的にはずっと簡単に拡張できます。

Answer 2

戦略を使用すると、実行時にアルゴリズムを簡単に追加できます。私の工場では、十分なはずですが、理論ごとに、戦略+工場があなたに合っているはずです。

Answer 3

戦略パターン（もう一度）は「必須」ではありませんが、あなたのニーズに合ったときには簡単です。基本的な考え方は、共通の概念（ソート）に複数の実装を持たせることができるということです。上記の例と同じように、戦略パターンを使用すると、既存のクライアントを変更することなく、「ソート」の実装をさらに追加することができます。

新しい「SortByUser」の新しい要件を受け取ったとしましょう。この新しいタスクでは、メソッドgetSortString（）を使用してSortStrategyInterfaceを実装する必要があります。そこから、古いクライアントには意図しない副作用がなく、新しい/変更されたクライアントはこの新しいソート戦略にアクセスできます。私の経験では、戦略パターンは自然に出現するパターンです。元の要件でコンセプトに対する「代替」（キーワード）アプローチが求められるときは、ほぼすぐに戦略パターンを考えることができます。