Java の 3 つのファクトリ モード

適用可能な場合:
7.3 ファクトリ パターンの適用可能な場合

新しいオブジェクトを作成する最も簡単な方法は、 new キーワードと具象クラスを使用することです。特定の状況でのみ、オブジェクト ファクトリの作成と維持が非常に複雑になる価値があります。このセクションでは、これらの出来事を要約します。

7.3.1 動的実装

前の自転車の例のように、同じインターフェイスをさまざまな方法で実装するオブジェクトを作成する必要がある場合は、ファクトリ メソッドまたは単純なファクトリ オブジェクトを使用して、実装を選択するプロセスを簡素化できます。 。この選択は、明示的または暗黙的に行うことができます。前者は自転車の例に似ており、顧客は必要な自転車のモデルを選択できます。次のセクションの XHR ファクトリーの例は後者に属します。この例で返される接続オブジェクトのタイプは、検出された帯域幅とネットワーク遅延に応じて異なります。時間やその他の要因。このような状況では、通常、同じインターフェイスを実装し、同等に扱うことができる一連のクラスを扱うことになります。これが、JavaScript でファクトリー パターンを使用する最も一般的な理由です。

7.3.2 セットアップのオーバーヘッドを節約する

オブジェクトが相互に関連する複雑な設定を必要とする場合、ファクトリ パターンを使用すると、各オブジェクトに必要なコードの量を削減できます。これは、特定のタイプのすべてのインスタンスに対してこのセットアップを 1 回だけ行う必要がある場合に特に便利です。この種のセットアップ コードをクラスのコンストラクターに含めるのは効率的ではありません。セットアップ作業が完了しても、新しいインスタンスが作成されるたびにコードが実行され、セットアップ コードがさまざまなクラスに分散されるためです。ファクトリメソッドはこの状況に非常に適しています。必要なオブジェクトをすべてインスタンス化する前に、一度セットアップすることができます。このアプローチでは、インスタンス化されるクラスの数に関係なく、セットアップ コードが 1 か所に保持されます。

これは、使用しているクラスで外部ライブラリをロードする必要がある場合に特に便利です。ファクトリ メソッドは、これらのライブラリを確認し、見つからないライブラリを動的にロードできます。これらの設定コードは 1 か所にのみ存在するため、後で変更するのがはるかに簡単です。

7.3.3 多くの小さなオブジェクトを使用して大きなオブジェクトを形成する

ファクトリ メソッドを使用して、多くの小さなオブジェクトをカプセル化するオブジェクトを作成できます。自転車オブジェクトのコンストラクターを考えてみましょう。自転車には、車輪、フレーム、トランスミッション コンポーネント、ブレーキなどの小さなサブシステムが多数含まれています。ファクトリ メソッドは、サブシステムをより大きなオブジェクトに強く結合したくないが、実行時に多くのサブシステムから選択したい場合に最適です。このテクノロジーを使用すると、ある日、販売するすべての自転車に特定のチェーンを取り付け、翌日さらに気に入った別のチェーンを見つけたら、その新しい種類に切り替えることができます。これらの自転車クラスのコンストラクターは特定のチェーンの種類に依存しないため、この変更の実装は簡単です。この章で後述する RSS リーダーの例では、この点でのファクトリ パターンの使用法を示します。


ファクトリ パターンは主にオブジェクトを作成するためのインターフェイスを提供します。ファクトリ パターンは、「Java とパターン」の定式化に従って、次の 3 つのカテゴリに分類されます。
1. シンプル ファクトリ パターン (Simple Factory)
2. ファクトリ メソッド パターン (Factory Method)
3.これら 3 つのパターンは、上から下に向かって徐々に抽象的かつ一般的になります。単純なファクトリ パターンをファクトリ メソッド パターンの特殊なケースとみなして、両者を 1 つのカテゴリに分類する分類方法もあります。ファクトリ パターンを使用する場合は次の 2 つの状況があります:
1. コーディング時にどのクラス インスタンスを作成する必要があるかを予測することは不可能です。
2. システムは、製品クラスのインスタンスがどのように作成、結合、表現されるかという詳細に依存すべきではありません


3. シンプルなファクトリー パターン
名前が示すように、このパターン自体は非常に単純で、ビジネスが比較的複雑な場合に使用されます。単純。
これは 3 つの役割で構成されます (関係については以下のクラス図を参照):
1. ファクトリーの役割: これはこのモデルの中核であり、特定のビジネス ロジックと判断ロジックが含まれています。 Java では、多くの場合、具象クラスによって実装されます。
2. 抽象的な製品の役割: 通常、特定の製品または実装されたインターフェイスによって継承される親クラスです。 Javaではインターフェースまたは抽象クラスによって実装されます。
3. 特定の製品ロール: ファクトリ クラスによって作成されたオブジェクトは、このロールのインスタンスです。 Javaの具象クラスによって実装されます。
それでは、シンプルなファクトリーモードを使用するにはどうすればよいですか?例を挙げてみましょう。長い理論的な説明よりも、この方がはるかに理解しやすいと思います。その成り上がり者を扱いましょう: P
シンプルなファクトリーモードを使用した後、成り上がり者は車に座ってドライバーに「運転して」と言うだけで済みます。どのように実装されるかを見てみましょう:
//抽象的な製品の役割
public インターフェース Car{
public void drive();
}
//特定の製品の役割
public class Benz は Car{
public void drive() {
System. out.println("運転中のベンツ ");
}
}
public class BMW は Car{
public void drive() {
System.out.println("運転中の BMW ");。 。 。 (アウディについては書きません:P)
//ファクトリ クラス ロール
パブリック クラス Driver{
//ファクトリ メソッド
//戻り値の型は抽象プロダクト ロールであることに注意してください
public static Car driverCar(String s)throws Exception {
/ /ロジックを判断し、特定の製品の役割をクライアントに返します
if(s.equalsIgnoreCase("Benz")) return new Benz();
else if(s.equalsIgnoreCase("Bmw"))
return new BMW();
...
それ以外の場合は、新しい Exception() をスローします。 。 。
//成り上がり者を歓迎します...
public class Magnate{
public static void main(String[] args){
try{
//運転手に今日はメルセデスに乗ると伝えてください
Car car = Driver.driverCar( "benz");
//コマンドを入力します: drive
car.drive(); 。 。
すべてのクラスを 1 つのファイルに入れる場合、パブリックに宣言できるクラスは 1 つだけであることを忘れないでください。 プログラム内のクラス間の関係は次のとおりです:
これは単純なファクトリー パターンです。その利点は次のとおりです:
まず第一に、単純なファクトリー パターンを使用した後、プログラムはもはや「問題」ではなくなり、より実際の状況に即したものになり、クライアントは製品オブジェクトを直接作成する責任が免除されます。そして、（成金がそうするように）製品を「消費する」ことだけに責任があります。
単純な工場モデルを開閉原理から分析してみましょう。新興企業が車を追加する場合、抽象製品によって確立された契約に準拠している限り、工場クラスに通知されている限り、顧客はその車を使用できます。したがって、製品部分については、オープン/クローズ原則 (拡張にはオープン、変更にはクローズ) に準拠していますが、ファクトリ部分は理想的ではないようです。車が追加されるたびに、対応するビジネス ロジックをファクトリ クラスに追加する必要があるからです。と判断ロジックは、明らかに開閉の原則に違反しています。
このようなファクトリークラス (この場合はドライバーマスター) を、オールマイティークラスまたはゴッドクラスと呼びます。
ここで挙げた例は最も単純なケースですが、実際のアプリケーションでは、製品はマルチレベルのツリー構造になる可能性があります。単純なファクトリ パターンには、これらの製品に対応するファクトリ クラスが 1 つしかないため、これは私たちの神のクラスを壊し、私たちの素敵なプログラマを疲れさせる可能性があります:(
前に述べたように、単純なファクトリ パターンはビジネスに適しています。単純な場合には、複雑なビジネス環境には適していない可能性があります。ここでファクトリ メソッド パターンが登場します。
4. まずその構成を見てみましょう:
1. 抽象化ファクトリ メソッド パターンの核心です。アプリケーションとは関係ありません。特定のファクトリ ロールが実装する必要があるインターフェイス、または継承する必要がある親クラスです。 : 特定のビジネス ロジックに関連するコードが含まれます。
3. 対応する特定の製品オブジェクトを作成するアプリケーション。Java では、特定の製品によって継承される親クラスです。
4. 特定の製品の役割: 特定のファクトリの役割によって作成されたオブジェクトは、Java の特定のクラスによって実装されます。
引き続き、完全な例を使用してその方法を確認します。言い換えれば、新興企業のビジネスはますます大きくなり、すべての車を覚え、維持し、使用する必要があるのです。そこで成り上がり者は彼に同情し、こう言いました。「これは、あなたと私が何年も続けてきたからです。さあ、あなたは将来それほど一生懸命働く必要はありません。私があなたに数人を割り当てます、あなただけが必要です」。それらを処理するため、ファクトリ メソッド パターンの管理は次のようになります:
//抽象的な製品の役割、具体的な製品の役割と単純さ ファクトリ パターンは似ていますが、少し複雑です。ここでは省略します。 Benz();
}
}
public class BmwDriverimplements Driver{
public Car driverCar() {
return new Bmw();
}
....//これは、特定の製品、ここに少し...
//成り上がりさんを招待してください
public class Magnate
{
public static void main(String[] args)
{
try{
Driver driver = new BenzDriver();車 car = ドライバー .driverCar();
car.drive()
}catch(Exception e)
{ }
}
}
ファクトリ メソッドは、単純なファクトリ パターンのコアとして具象クラスを使用するのではなく、抽象ファクトリ ロールをコアとして使用します。ファクトリ メソッド パターンが何をもたらすか見てみましょう。開閉原理を使用してファクトリ メソッド パターンを分析します。新しい製品 (新興企業向けの自動車など) が生産される場合、抽象製品ロールと抽象工場ロールによって提供される契約に従って生成されている限り、既存のコードを変更することなく、顧客がその製品を使用できます。ファクトリーメソッドのパターンは開閉原理と完全に一致しているようです。
ファクトリ メソッド パターンを使用すれば、遭遇する可能性のあるほとんどのビジネス ニーズを満たすのに十分です。しかし、製品の種類が多い場合、対応するファクトリ クラスの数も多数になるため、これは望ましいことではありません。したがって、この場合は、単純なファクトリ パターンとファクトリ メソッド パターンを使用してファクトリ クラスを減らすことをお勧めします。つまり、製品ツリー上の同様のタイプ (通常はツリーの葉の兄弟) には、単純なファクトリ パターンを使用します。達成するために。
もちろん、特殊な状況には特別な処理が必要です。システム内に異なる製品ツリーがあり、製品ツリー上に製品ファミリーがある場合、この場合には抽象ファクトリ パターンが使用されることがあります。
V. 概要
単純なファクトリ パターンとファクトリ メソッド パターンから得られるインスピレーションを見てみましょう:
この例を実装するためにファクトリ パターンを使用しない場合、コードは大幅に削減される可能性があります。既存の車を実装する必要がありますが、ポリモーフィズムは使用しません。ただし、保守性と拡張性の点では非常に貧弱です (車を追加した後に影響を受けるクラスは想像できるでしょう)。したがって、スケーラビリティと保守性を向上させるために、より多くのコードを記述する価値があります。
6. 抽象的なファクトリー パターン
まず、製品ファミリーとは何か、つまり、さまざまな製品階層構造に配置された関連機能を持つ製品ファミリーを理解しましょう。この文章を読んだだけで、この概念が明確に理解できたなら、私はあなたに感心するしかありません。例を使ってそれをわかりやすく説明しましょう。
写真の BmwCar と BenzCar は 2 つの製品ツリー (製品階層) であり、写真に示されている BenzSportsCar と BmwSportsCar は 1 つの製品ファミリーです。これらはすべてスポーツカーファミリーに分類できるため、機能は関連しています。同様に、BMWBussinessCar と BenzSportsCar も製品ファミリーです。
抽象プロダクト パターンの話に戻りますが、ファクトリ メソッド パターンとの違いは、作成する必要があるオブジェクトの複雑さにあると言えます。さらに、抽象ファクトリー パターンは、3 つの中で最も抽象的かつ一般的です。抽象ファクトリ パターンの目的は、複数の製品ファミリーの製品オブジェクトを作成できるインターフェイスをクライアントに提供することです。さらに、抽象ファクトリー パターンを使用するには、次の条件を満たす必要があります:
1. システム内に複数の製品ファミリーがあり、システムは一度に 1 つの製品のみを使用できます
2.に応じて使用できます。
抽象ファクトリ パターンのさまざまな役割を見てみましょう (ファクトリ メソッドの役割と同じ):
抽象ファクトリの役割: これはファクトリ メソッド パターンの中核であり、アプリケーションとは何の関係もありません。これは、特定のファクトリ ロールが実装する必要があるインターフェイス、または継承する必要がある親クラスです。 Java では、抽象クラスまたはインターフェイスによって実装されます。
特定のファクトリ ロール: 特定のビジネス ロジックに関連するコードが含まれています。特定の製品に対応するオブジェクトを作成するためにアプリケーションによって呼び出されます。 Java では、具象クラスによって実装されます。
抽象的な製品の役割: 特定の製品または実装されたインターフェイスによって継承される親クラスです。 Java では、通常、実装する抽象クラスまたはインターフェイスが存在します。
特定の製品ロール: 特定のファクトリ ロールによって作成されたオブジェクトは、このロールのインスタンスです。 Java の特定のクラスによって実装されます。
最初の 2 つのモードを見れば、このモードでのさまざまなキャラクター間の調整についてのアイデアが得られるはずです。そのため、具体的な例は示しません。抽象ファクトリーパターンを使用するための条件を必ず満たしてください。そうでない場合、複数のプロダクトツリーがあっても、プロダクトファミリーもありますが、それらは使用できません

3つのJavaに関連するその他の記事はこちら工場出荷時のパターンについては、PHP 中国語 Web サイトに従ってください。