0

フォーラムでこれを見つけましたが、よく説明されているようです：

戦略は、アルゴリズムのクライアントを壊すことなく、ソフトウェアに新しい (あなたの場合はソート) アルゴリズムを追加できるようにすることを目的としたパターンです。クライアントを壊すことなく新しいアルゴリズムを追加する必要がある場合、これは設計の複雑さへの投資です。Factory は Strategy を補完するパターンです。これは、アルゴリズム実装のクライアントが (ソフトウェア クラスに関して) 使用している実装を具体的に認識してはならないためです。ファクトリはアルゴリズムの具体的な実装をインスタンス化するため、クライアントは詳細を知らなくても使用できます。

ここに画像の説明を入力

ここに画像の説明を入力

ただし、SortStrategtyInterface の必要性を理解することはできません。ファクトリにソート文字列を返すように依頼しないでください。

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

4

3 に答える 3

0

戦略パターン（もう一度）は「必要」ではありません。その使用がニーズに合っている場合に備えておくと便利です。基本的な考え方は、共通の概念（並べ替え）に対して複数の実装を持つことができるということです。上記の同じ例から脱却すると、戦略パターンにより、既存のクライアントに変更を加えることなく、「sort」の実装をさらに追加できます。

新しい「SortByUser」の新しい要件を受け取ったとしましょう。この新しいタスクでは、メソッドgetSortString（）を使用してSortStrategyInterfaceを実装するだけでなく、ファクトリに数行作成するだけで済みます。そこから、古いクライアントには意図しない副作用がなくなり、新しい/変更されたクライアントはこの新しい並べ替え戦略にアクセスできるようになります。私の経験では、戦略パターンは最も頻繁に自然に現れるものです。元の要件が概念への「代替」（キーワード）アプローチを要求するときはいつでも、ほとんどすぐに戦略パターンを考えることができます。

于 2012-04-16T12:23:46.020 に答える
0

インターフェースは必ずしも「必要」というわけではありませんが、クライアントとさまざまなソート アルゴリズムとの間の契約を保証するためにインターフェースを用意する方が断然優れています。このコントラクトは、ファクトリから返された戦略にメソッド「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();

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

于 2012-04-16T11:08:47.057 に答える
-1

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

于 2012-04-16T06:47:38.850 に答える