06、工場出荷時のモード - ファクトリメソッドパターン

2019ユニコーン企業重く募集エンジニアのPythonの標準>>>

シンプルなファクトリパターン学習の前でよりFactory Methodパターン。

シンプルな工場では、それは言われていて、シンプルな工場パターンの欠点があります：

私はシステムを拡張したい場合は、新しい製品カテゴリに加えて、製品クラスを追加する必要がなく、OCPを満たしていないファクトリクラスを、調整する必要があります。

それでは見て、工場法のパターンは、この問題を解決する方法です。

依然として上記の例を使用して：

まず、抽象クラスの定義と抽象クラスの人々の人々ファクトリクラスを作成するには - 仮にこの言葉はもはや反映されている工場、PeopleCraetorそれと呼ばれていません。次のように：

package com.yp.learn.designmodel;
public abstract class People {
abstract void say();
}
package com.yp.learn.designmodel;
public abstract class PeopleCreator {
public abstract People createPeople();
}

クラスの中国を定義した後、アメリカ人、およびこれら2つのクラスは人々のカテゴリを継承します。次のように：

package com.yp.learn.designmodel;
public class Chinese extends People {
@Override
void say() {
System.out.println("说汉语");
}
}
package com.yp.learn.designmodel;
public class American extends People {
@Override
void say() {
System.out.println("Say American English");
}
}

そして、これら2つのクラスは、特に工場のこれら2つのクラスを生成したファクトリを作成し、工場はPeopleCreatorクラスを継承しています。次のように：

package com.yp.learn.designmodel;
public class AmericanCreator extends PeopleCreator {
@Override
public People createPeople() {
// TODO Auto-generated method stub
return new American();
}
}
package com.yp.learn.designmodel;
public class ChineseCreator extends PeopleCreator {
@Override
public People createPeople() {
// TODO Auto-generated method stub
return new Chinese();
}
}

カテゴリのリスト全体をスクリーンショットは次のとおりです。

最後に、クライアントのコードを見て：

package com.yp.learn.designmodel;
public class Start {
public static void main(String[] args) {
// TODO Auto-generated method stub
People p ;//定义抽象类变量
PeopleCreator peopleCreator ;//定义抽象类工厂变量
peopleCreator = new ChineseCreator();//依据实际业务而言所调用的实际产品工厂类。
p = peopleCreator.createPeople();
peopleCreator = new AmericanCreator();
p.say();
p = peopleCreator.createPeople();
p.say();
}
}

結果：

分析：

今クラスに来るクライアント、見て：

1、抽象クラスの人々は：このクラスは、異なる実装に基づいて、可変、異なる動作を達成するために、Javaのと組み合わせて、このような多型の機能を通じて、抽象製品クラスのメソッドが含まれています。一例は、二回のp実装されますが、同じ方法で実行が異なると言うの結果です。

図2は、抽象ファクトリクラスの人を作成する抽象クラスを持つ人々は、そのような例として、製造プラントを定義し、インスタンスに抽象クラスリファレンスを定義する責任があります。しかし、完成されたそのサブクラスによってそれを実現しています。

3、工場製品カテゴリの具体的な実現を生成するために、実際の製品のファクトリクラスを作成します。

私は今、ソフトウェアを展開する必要がある場合は、その後、私は次の操作を行う必要があり、フランス語を追加する必要があります。

1、FRANCH、相続人を追加

2、FranchCreator、継承を追加PeopleCreator

変数に割り当て3、クライアントコード、peopleCrator peopleCreator = FranchCreator（）に調整し;

残りの部分は変更されません。

今、中国の人々とファクトリクラスとそのアメリカのファクトリクラスコードに関連して、元のビジネス・ロジックは、何ら変化は発生せず、システムの開発が、新しいクラスの方法によって達成されていたが、比較します。これは、解決するために、単純なファクトリパターンの欠点を有しています

あなたは疑問であってもよいです。

1は、クライアントコードが変更され、またはOCPに準拠していません。

：クライアントは、実際の需要の変化と、それは顧客の需要が変化することはありませんしない限り発生しませんクライアントコードの変更を制御することができないので、OCPは、コードの意味の範囲内でサービス層ではなく、クライアントのコードです。同じ（レイヤーモードのビジネスソフトウェア）現状（顧客ニーズ）を達成するために。

2、クライアントコードがあった中国とアメリカ人に、例えば、すなわち、クライアントがあることをどのインスタンスかを知る必要があり、この時間は、なぜ単に新しいキーワードインスタンスオブジェクトを使用しますが、あまりにも面倒ではありませんか？

A：この質問は正常ですが、検討する、この時間は、問題を見てではなく、コードの実装をルックアップするためにビューのソフトウェアの設計ポイントからです。その意図は、つまり、工場出荷時のモデルを分離することで作成されたオブジェクトがクライアントによって反映すべきではありません。クライアントが関係するので、使うのではなく作成することです。しかし、使用前にそこに作成する必要があり、その後、Factory Methodパターンは、ファクトリクラスの一部に作成され、クライアントコードは、ライン上の製品カテゴリへ直接関連する使用しています。しかし、それはまた、クライアントでは、このような状況を作成したファクトリクラスを紹介します。比較すると、しかし、クライアントファクトリクラスで作成され、クライアント側でクラスの製品を作成し、あなたはかつてより多くの柔軟性が良いでしょう。

学習は、学習コードを達成するのではなく、注意を払うが、設計を理解しなければなりません。

OCPを解決するために、単純なファクトリパターンと比較が図3は、しかしながら、単純なファクトリパターンは、唯一のライン上のクライアントでファクトリクラスを作成し、ファクトリクラス、入手可能な製品の種類によってパラメータを渡す必要はなく、ファクトリメソッドパターン、一見ではないような単純な方法ではなく、製品のファクトリクラスを指定することで、抽象ファクトリクラスをインスタンス化する必要があり、その後、クライアントは、まだ終わりではファクトリクラスが選択された製品を決定するために存在しなかったでしょうか？つまり、クライアントコードは、顧客と選択されたコンテンツ製品カテゴリに対応する選択されたコンテンツとの間のマッピング関係を維持する必要がありますか？

A：この問題は、人権侵害のFactory Methodパターンです。確かに、比較的単純なファクトリパターン、Factory Methodパターンは、このような問題が存在しない、のいずれかのモードが条件排除することは絶対に不可能である、唯一の条件付き転送と言うことができます。

要約：

1、デカップリングを達成するためのstaticファクトリパターンは、しかし、OCPに従っていません

2、OCPを達成するためのファクトリメソッドパターンが、デカップリングが良い行われ、静的なファクトリパターンではありません

あなたはこの2つの問題に共通の解決策にしたい場合は、Javaのリフレクション技術によって実現されます。この性能は、春には非常に顕著です。

ノートから知られている（ウィズ）

ます。https：//my.oschina.net/u/1182369/blog/406569で再現

06、工場出荷時のモード - ファクトリメソッドパターン

おすすめ