実行時に、ユーザーの動作と履歴に基づいて、並べ替え操作を実行する必要があります。私の場合、SortByDate/SortByDemand/SortByConsumptionは文字列を返すだけです。または、order by句（複雑な場合もあります）と言うことができます。
ほとんどのフォーラムで、ソートには戦略パターンを使用する必要があることがわかりました。
ストラテジーパターンの画像をここに添付しました。Utilクラスは、3つのクラスのうちの1つのオブジェクト、つまり、SortByDate / SortByDemand/SortByConsumptionを呼び出します。
したがって、新しい並べ替え方法を定義するたびに、utilクラスを変更し、新しいストラテジーを定義する必要があります。
ただし、ファクトリを使用して実装した場合、utilクラスはファクトリを呼び出すだけで、呼び出すクラスを処理します。だから私は工場を使うべきだと思います。
しかし、私は戦略がそのようなニーズに最適なパターンであることを読みました。なぜここで戦略パターンが優れているのですか？
あなたがしたことはファクトリパターンではなく、両方の組み合わせであり、それは明確ではなく、私の意見では間違っています。
2番目の例では、クラス名が間違っていて混乱しています。SortByDateFactory工場のようには動作しませんが（何も生成しません）、戦略のように動作します。したがって、戦略インターフェースに準拠する必要があります。
一方、最初の例では、UtilClass作成したいファクトリのように動作します。したがって、最初の例はそのままにして、名前をに変更することをお勧めしUtilClassますSortStrategyFactory。
これらの図はどちらも戦略パターンのように見えますが、下の図は少し詰まっています。ファクトリが必要な場合は、utilclassが抽象であり、ソータクラスをインスタンス化するファクトリメソッドを持つことを意味します。utilclassの特定のサブクラスによって定義された特定のタイプのソーター。
戦略パターンのポイントは、クラス階層に縛られることを避け、さまざまなソーターを他のさまざまな機能と組み合わせて組み合わせることができるようにすることです。utilclassのサブクラスを使用している場合、ファクトリは適切であり、特定のサブクラス（残りのすべての機能を含む）は常に特定のソーターを必要とし、別のソーターは必要ありません。ニーズに基づいて適切なものを選択してください。
ストラテジーは、アルゴリズムのクライアントを壊すことなく、ソフトウェアに新しい（場合によってはソート）アルゴリズムを追加できるようにすることを目的としたパターンです。これは、クライアントを壊すことなく新しいアルゴリズムを追加する必要がある場合に報われる、設計の複雑さへの投資です。ファクトリは、アルゴリズム実装のクライアントが（ソフトウェアクラスの観点から）使用している実装を具体的に知る必要がないため、ストラテジーを補完するパターンです。ファクトリはアルゴリズムの具体的な実装をインスタンス化するため、クライアントは詳細を知らなくてもそれらを使用できます。
静的構造は次のとおりです。
ダイナミックは次のとおりです。
工場と戦略の両方を効果的に使用しています。工場は、作成する戦略を決定します。戦略はソートロジックを実行します。
工場から戦略を継承しているため、下の図は混乱を招きます。工場は正しい戦略を作成する必要があります。
クライアントは工場に戦略を要求し、それを使用します。