目的のモード
オブジェクトを作成するためのインタフェースの定義は、サブクラスは、インスタンスのどのクラスを決めましょう。
ファクトリメソッドでインスタンス化クラスモデルは、サブクラスを延期します。
モード構造
パート
- 生成物(製品)
-インタフェースの製品の機能を定義します - 特定の製品(ConcreteProduct)
-製品のインタフェースを達成するために特定の製品 - 工場(クリエイター)
-ファクトリインタフェースの関数を定義 - 特定の植物(コンクリート)
-特定の植物工場インタフェースを達成するために
達成JAVA
プラントモデル、及びメルセデスベンツ自動車工場の生産、BMW例用いる方法
自動車製品は、インタフェースICARとして定義されている
インタフェースICarFactoryとして定義される植物、自動車工場、
コードUMLクラス図以下:
BMW工場の使用getInstance()
メルセデスベンツの工場使用して、BMWの車を作成する方法をgetInstance()
メルセデスを作成する方法を。
次のように関連するコードは次のとおりです。
ICar.java
public interface ICar {
/**
* 实现类必须实现run()方法
**/
void run();
}
BmwCar.java
public class BmwCar implements ICar{
@Override
public void run() {
System.out.println("This is Bmw running");
}
}
BenzCar.java
public class BenzCar implements ICar{
@Override
public void run() {
System.out.println("This is Benz running");
}
}
ICarFactory.java
public interface ICarFactory {
/**
* 实现类必须实现getCar()方法
**/
ICar getCar();
}
BmwFactory.java
public class BmwFactory implements ICarFactory {
@Override
public ICar getCar() {
return new BmwCar();
}
}
BenzFactory.java
public class BenzFactory implements ICarFactory {
@Override
public ICar getCar() {
return new BenzCar();
}
}
クライアントのテストコードと出力を次のように
Client.java
public class Client {
public static void main(String[] args) {
ICarFactory carFactory = new BenzFactory();
carFactory.getCar().run();
ICarFactory carFactory2 = new BmwFactory();
carFactory2.getCar().run();
}
}
出力:
This is Benz running
This is Bmw running
モード利点
- が、また、特定の製品クラスは、この詳細をインスタンス化される隠して顧客に顧客が必要とする製品を作成するためのファクトリメソッドパターン、ファクトリメソッドでは、唯一の植物を心配する必要はユーザーが作成した気にせずに対応する製品のために必要詳細は、あるいはクラスの特定の製品カテゴリの名前を知っています。
- 多型のプラント設計は、製品の役割と性格に基づいてキーFactory Methodパターンです。これは、植物が自律的にどのように完全にコンクリート工場でカプセル化されたオブジェクトの詳細を作成する製品のオブジェクトが作成されるかを決定し、することができます。工場モードの方法はまた、多型工場モードと呼ばれている理由、同じ抽象親クラスを持つ特定のファクトリクラスのすべてのため。
- ファクトリメソッドを使用してのもう一つの利点は、システム内の新製品に添加され、抽象工場や製品抽象インタフェースを変更せずに、クライアントを変更することなく、限り、特定の植物が追加されると、特定の植物やその他の特定の製品を変更する必要はありませんそしてその上に特定の製品。このため、システムの拡張性は、非常に良い、完全準拠となり、「開閉の原則。」
モードの欠点
- 新製品を追加するときに、あなたが特定の製品の新しいクラスを記述することなく、対応する具体的なファクトリクラスを提供する必要があり、クラスのシステムは増加の対の数は、ある程度のシステムの複雑さは、より多くありますクラスは、コンパイルして実行する必要があり、いくつかの追加のオーバーヘッドシステムをもたらすでしょう。
- アカウントにシステムのスケーラビリティを取って、抽象層の導入を必要とする、クライアントコードを使用して抽象化レイヤで定義され、システムは、抽象化と理解の困難さを増加させ、実装された場合DOM、反射技術を使用する必要があるかもしれませんシステムを実装することの難しさを増します。
概要
- ファクトリメソッドパターンは、スキーマを作成するクラスに属する工場モデルとして知られています。ファクトリメソッドモードでは、工場出荷時の親クラスは、製品のオブジェクトのパブリックインターフェイスを作成して定義するための責任があり、工場のサブクラスは、特定の対象物を生成するための責任があり、その目的は、完成した植物のサブクラスへの製品クラスの遅延のインスタンス化操作にありますすなわち、インスタンス化するために特定の製品クラスファクトリサブクラスかどうかを決定することによって。
- ファクトリメソッドパターンは、4つのロールからなる:抽象製品は、製品インタフェースはスーパータイプであること、共通の親の製品はクラスまたはインタフェースオブジェクト作成されたオブジェクトのファクトリメソッドパターンで定義され、特定の製品が抽象製品インターフェイスを達成するために、特定のいくつかのタイプを専門的な植物特異的、それらの間の多くの場合、1対1の対応で作成された製品、抽象工場の製品を返品するために使用されるファクトリメソッドを宣言し、それは、Factory Methodパターンの中核である、任意のファクトリクラスをスキーマ内のオブジェクトを作成するには、実装する必要があります。インターフェース;コンクリートファクトリクラスは抽象ファクトリのサブクラスであり、工場の実装定義された抽象ファクトリメソッドは、クライアントによって呼び出され、特定の製品クラスのインスタンスを返すことができます。
- ファクトリメソッドパターンはさらにシンプルかつAbstract Factoryパターンを促進することです。オブジェクト指向のポリモーフィズムの使用、シンプル保持モードファクトリメソッドファクトリパターンの利点に、その欠点を克服します。Factory Methodパターンでは、ファクトリクラスのコアは、もはやすべての製品を作成するための責任がありませんが、それを行うには、特定のサブクラスを作成していきます。コアクラスは、Factory Methodパターンは、システムが役割を変更することなく、工場で新製品を投入できるようにすることができますこのような詳細をインスタンス化された製品クラス、責任を負いません実装されなければならない植物特有のインタフェースに対してのみ責任を与えられています。
- プラントモデルの主な利点は、システムが良好な柔軟性と拡張性を持って、製品の新しいクラスを追加すると、オブジェクトの作成の詳細の製品を包装することなく、既存のシステムを変更するための方法であり、同時に新製品を追加することの不利な点は、新しいを追加する必要があります植物は、システムクラスのペアの数を増加させることで、その結果、ある程度、システムの複雑さを増大させます。
- ファクトリメソッドパターン適用には、次のとおりです。クラスは知りません、それはクラスオブジェクトを必要とする;クラスは、オブジェクトが作成されるサブクラスによって指定され、サブクラスでクライアントに工場数を委託し、特定のタスクのオブジェクトを作成します製品にサブカテゴリを作成するには、サブクラスファクトリであるかもしれないものを気にせずに使用し、必要に応じてその後、動的に割り当てられたとき。