なぜソート用のファクトリパターン？

Question

実行時に、ユーザーの動作と履歴に基づいて、ソート操作を実行する必要があります。私の場合、SortByDate/SortByDemand/SortByConsumptionは単に文字列を返すか、order by節（これは複雑かもしれません）と言うことができます。

ほとんどのフォーラムでは、ソートに戦略パターンを使用する必要があります。

私はここでの戦略パターンの画像を添付しています。 Utilクラスは、SortByDate/SortByDemand/SortByConsumptionの3つのクラスのオブジェクトを呼び出します。

ソートの新しい方法が定義されるたびに、utilクラスを変更して新しい戦略を定義する必要があります。しかし、私は工場を使用して、それを実装した場合

は、utilのクラスは、単に工場を呼び出す必要があり、それが呼び出すためにどのクラスの世話をします。だから私は工場を使うべきだと思う。

しかし、私はその戦略がそのようなニーズのための最良のパターンであることを読んだ。なぜ戦略パターンはここで良いですか？

Answer 1

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

がここに静的な構造です：

ここでダイナミックです：

Answer 2

あなたがしたことは、工場のパターンではなく、両方が混在しています。これは明確ではなく、間違っています。

2番目の例では、クラス名が間違っていて混乱します。 SortByDateFactoryは、ファクトリのようには動作しません（何も生成されません）が、戦略のように動作します。したがって、戦略インタフェースに準拠する必要があります。

一方、最初の例では、UtilClassは、作成するファクトリのように動作します。したがって、最初の例をそのままにしておき、UtilClassという名前をSortStrategyFactoryに変更することをお勧めします。

Answer 3

これらの図は両方とも戦略パターンのように見えますが、下のものは少し伏せてあります。ファクトリが必要な場合、utilclassは抽象クラスであり、ファクトリメソッドを持ち、ソートクラスをインスタンス化します。 utilclassの特定のサブクラスによって定義されるソートの特定のタイプ。

戦略パターンのポイントは、クラス階層に縛られないようにすることで、さまざまなソーターをさまざまな機能と組み合わせて組み合わせることができます。あなたがutilclassのサブクラスと特定のサブクラスを使用しているときは、そのファクトリは適切です（残りのすべての機能は常に特定のソートを必要とします）。必要に応じて適切なものを選択してください。

Answer 4

工場との戦略の両方を効果的に使用しています。 工場は、戦略を作成するかどうかを決定します。 ストラテジがソートロジックを実行します。

工場からの戦略を継承しているため、下図が混乱しています。工場はちょうど正しい戦略を作成する必要があります。

クライアントは、工場に戦略を尋ねてそれを使用するだけです。