回答:
ファクトリー・パターンは創造的なパターンです。戦略パターンは運用パターンです。言い換えれば、ファクトリパターンは特定のタイプのオブジェクトを作成するために使用されます。戦略パターンは、特定の方法で操作（または操作のセット）を実行するために使用されます。古典的な例では、ファクトリーはさまざまなタイプの動物（犬、猫、虎）を作成し、戦略パターンは特定のアクション（移動など）を実行します。ラン、ウォーク、またはロープ戦略を使用します。
実際、この2つは一緒に使用できます。たとえば、ビジネスオブジェクトを作成するファクトリがあるとします。永続化メディアに基づいて異なる戦略を使用する場合があります。データがローカルでXMLに格納されている場合、1つの戦略が使用されます。データが別のデータベースのリモートにある場合は、別のデータベースを使用します。
tvanfossonの発言に加えて、多くのパターンは実装に関しては同じに見えます。つまり、多くの場合、コードに以前はなかったインターフェイスを作成してから、そのインターフェイスの実装の束を作成します。違いは、目的と使用方法にあります。
具象インスタンスのみを作成します。引数が異なると、オブジェクトが異なる可能性があります。ロジック等により異なります。
アルゴリズム（steps）をカプセル化してアクションを実行します。したがって、戦略を変更して別のアルゴリズムを使用できます。
どちらも非常によく似ていますが、目的はかなり異なります。1つはアクションを作成すること、もう1つはアクションを実行することです。
そう。Factoryメソッドが修正されている場合は、次のようになります。
public Command getCommand( int operatingSystem ) {
switch( operatingSystem ) {
case UNIX :
case LINUX : return new UnixCommand();
case WINDOWS : return new WindowsCommand();
case OSX : return new OSXCommand();
}
}ただし、工場でより高度な動的な作成が必要だとします。ファクトリメソッドに戦略を追加して、再コンパイルせずに変更できます。戦略は実行時に変更される可能性があります。
まず最初に、単純なファクトリーと抽象的なファクトリーの違いを作らなければなりません。最初のものは、オブジェクト作成のファクトリーとして機能するクラスが1つしかない単純なファクトリーです。後者では、ファクトリーインターフェース（メソッド名を定義する）に接続し、このインターフェースを実装するさまざまなファクトリーを呼び出します。いくつかの基準に基づいて、同じメソッドの異なる実装を持つことになっています。たとえば、最初のWindowsButtonCreationFactory（Windowsのルックアンドフィールでボタンを作成）と2番目のLinuxButtonCreationFactory（Linuxのルックアンドフィールでボタンを作成）の2つのファクトリによって実装されるButtonCreationFactoryインターフェイスがあります。したがって、これらの両方のファクトリは、異なる実装（アルゴリズム）で同じ作成メソッドを持っています。
たとえば、Linuxのルックアンドフィールのボタンが必要な場合：
ButtonCreationFactory myFactory = new LinuxButtonCreationFactory();
Button button1 = myFactory.createButton(...);または、Windowsボタンが必要な場合
ButtonCreationFactory myFactory = new WindowsButtonCreationFactory();
Button button1 = myFactory.createButton(...);まさにこの場合、何らかの作成を行うためのアルゴリズムを区別するため、一種の戦略パターンになります。ただし、操作アルゴリズムではなくOBJECT CREATIONに使用されるため、意味的に異なります。したがって、基本的に抽象ファクトリーでは、さまざまな戦略を使用してオブジェクトを作成するため、戦略パターンと非常によく似ています。ただし、抽象パターンは創造的であり、戦略パターンは機能しています。実装に関しては、結果は同じになります。
Factory（およびFactoryによって返されるFactoryMethod）：
このウィキペディアの記事とjavarevisitedの記事をご覧ください
戦略パターン：
例：
特定のアイテム（AirFareチケットまたはShoppingCartアイテム）の割引戦略を構成できます。この例では、7月から12月までのアイテムに25％の割引を提供し、1月から6月までのアイテムには割引を適用しません。
関連記事：
オスカーが言ったことを拡張し、彼のコードを参照するには：
getCommandはファクトリであり、UnixCommand、WindowsCommandおよびOSXCommandクラスは戦略です
コードやカテゴリを見ただけでは違いがわかりません。GoFパターンを正しく把握するには、その意図を探します。
戦略：「アルゴリズムのファミリーを定義し、それぞれをカプセル化し、それらを交換可能にします。戦略により、アルゴリズムを使用するクライアントとは独立してアルゴリズムを変えることができます。」
ファクトリメソッド：「オブジェクトを作成するためのインターフェースを定義しますが、インスタンス化するクラスはサブクラスに決定させます。ファクトリメソッドは、クラスがインスタンス化をサブクラスに遅延させるようにします。」
そして、ここにこれらの2つのパターンの意図と違いについての入念な説明があります：ファクトリーメソッドとストラテジーのデザインパターンの違い
ファクトリー実装の彼の例はかなり緊密に結合されており、非常に閉じているという点で、オスカーとは一言かもしれません。あなたの選択が戦略パターンであることも不思議ではありません。Factoryの実装は、インスタンス化される特定のクラスの固定数に依存してはなりません。次に例を示します。
public Command getCommand( int operatingSystem ) {
return commandTable.get(operatingSystem);
}
...
public class WindowsCommand implements Command {
...
static {
CommandTable.getInstance().registerCommand(WIN_COMMAND_ID, new WindowsCommand());
}
}どちらかを選択するのに最も適切な基準は、クラスとメソッドに名前を付けるために使用する用語であり、クラスではなくインターフェイスにプログラムする傾向があり、また目標に焦点を当てる必要があることを考慮します。実行時に実行されるコード。つまり、両方のパターンのいずれかを使用することで、目標を達成できます。
ファクトリパターンは、指定されたプロパティ（動作）で作成される作成パターンです。実行時の作成後は、プロパティ（動作）を変更できません。したがって、異なるプロパティが必要な場合（動作）、オブジェクトを削除して、必要なプロパティを持つ新しいオブジェクトを作成する必要があります（動作）。ガッドではありません。一方、戦略パターンの場合、uは実行時にプロパティ（動作）を変更できます。