ファクトリーパターンと戦略パターンの違いを説明できる人はいますか?
私にとって、両方とも追加のファクトリークラス(ファクトリーパターンで製品のオブジェクトを作成する)以外は同じように見えます
ファクトリーパターンと戦略パターンの違いを説明できる人はいますか?
私にとって、両方とも追加のファクトリークラス(ファクトリーパターンで製品のオブジェクトを作成する)以外は同じように見えます
まず、単純なファクトリと抽象ファクトリを区別する必要があります。最初のものは、オブジェクト作成のファクトリとして機能する 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 に使用されるため、意味的には異なります。したがって、基本的に抽象ファクトリでは、さまざまな戦略を使用してオブジェクトを作成するため、戦略パターンに非常に似ています。ただし、AbstractFactory は作成的ですが、Strategy パターンは操作可能です。実装に関しては、結果は同じになります。
具体的なインスタンスのみを作成します。異なる引数は、異なるオブジェクトになる場合があります。ロジックなどに依存します。
アクションを実行するアルゴリズム ( steps ) をカプセル化します。したがって、戦略を変更して別のアルゴリズムを使用できます。
どちらも非常に似ているように見えますが、目的はかなり異なります。一方の目的は作成であり、もう一方の目的はアクションを実行することです。
そう。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 つのファクトリは、具体的なクラス インスタンスのランタイム作成であり、実装されたインターフェイスによって公開された動作 (メソッド) を使用するのはあなた次第です。
ファクトリパターンは、指定されたプロパティ(動作)で作成される作成パターンです。作成後の実行時に、プロパティ(動作)を変更することはできません。したがって、異なるプロパティ(動作)が必要な場合は、オブジェクトを削除し、必要なプロパティ(動作)を使用して新しいオブジェクトを作成する必要があります。これはガッドではありません。一方、戦略パターンの場合、実行時にプロパティ(動作)を変更できます。
コードや分類だけを見ただけでは違いが分かりません。GoF パターンを正しく把握するには、その意図を探します。
戦略: 「アルゴリズムのファミリーを定義し、それぞれをカプセル化し、それらを交換可能にします。戦略により、アルゴリズムは、それを使用するクライアントとは独立して変化します。」
ファクトリ メソッド: 「オブジェクトを作成するためのインターフェイスを定義しますが、インスタンス化するクラスはサブクラスに決定させます。ファクトリ メソッドにより、クラスはインスタンス化をサブクラスに任せることができます。」
そして、これら 2 つのパターンの意図と違いについて詳しく説明します:ファクトリ メソッドとストラテジー デザイン パターンの違い
戦略と工場は別の目的です。戦略では、アプローチを定義し、このパターンを使用して動作 (アルゴリズム) を交換できます。Factoryに来ると、周りにたくさんのバリエーションがあります。しかし、GO4 の元のパターンでは、ファクトリはオブジェクトの作成を子クラスに任せています。ここでは、ファクトリを使用して、関心のある動作ではなく完全なインスタンスを置き換えています。これにより、アルゴリズムではなく完全なシステムを置き換えます。
Oscar の Factory 実装の例はかなり緊密に結合されており、非常に閉じているという点で脱線するかもしれませんが、あなたが Strategy パターンを選択したのも不思議ではありません。Factory の実装は、インスタンス化される特定のクラスの固定数に依存するべきではありません。次に例を示します。
public Command getCommand( int operatingSystem ) {
return commandTable.get(operatingSystem);
}
...
public class WindowsCommand implements Command {
...
static {
CommandTable.getInstance().registerCommand(WIN_COMMAND_ID, new WindowsCommand());
}
}
どちらかを選択するための最も適切な基準は、ほとんどの場合、クラスやメソッドに名前を付けるために使用する用語であると思います。これは、クラスではなくインターフェイスにプログラムする傾向があり、目標に焦点を当てる必要があることを考慮して、決定することを目指しています。実行時に実行されるコード。とはいえ、両方のパターンのいずれかを使用して目標を達成できます。
Factory Pattern
との主な違いStrategy Pattern
は、操作が行われる場所です。Factory Pattern
作成されたオブジェクトに対して操作を行います (ファクトリ クラスは作成後にジョブを実行します)Strategy Pattern
が、コンテキスト クラス自体に対して操作を行います。
Factory Pattern
aを aに変更するにはStrategy Pattern
、作成されたオブジェクトをファクトリ クラスから返す代わりに、オブジェクトをコンテキスト クラス内に保持し、コンテキスト クラス内にラッパー メソッドを作成して、作成されたオブジェクトから直接操作を実行する代わりに操作を実行します。
作成されたオブジェクトに対して操作を実行できるかどうかを尋ねる人がいるかもしれませんが、コンテキスト クラスで実行するラッパーを作成する必要があるのはなぜでしょうか? OK、重要なのは操作です。Strategy Pattern
戦略に基づいて操作を変更でき、オブジェクトを変更する必要はありません。オブジェクト自体を変更する代わりに、コンテキストオブジェクトに依存してさまざまな操作を実行できます。