プログラム猿として、我々は多かれ少なかれ、毎日多くのコードを書くことが、コードは良いスケーラビリティ、それを書かれていませんか？これは、読者の便宜のではないでしょうか？これはどのように書くために上のコードを書いたドナーである」、と言って、1日は「軽蔑彼は!!!！どの男の書き込みコードに」同僚、バックあなたを呼び出さない、あなたのコードを修正し、突然ですが、驚きました！とても美しい、とても良い老僧のエンド味!!!」
1.はじめに
インタビューのうち最近の新人、インタビュアーが（、彼らはそれを聞いてきたように、いくつかの一般的に使用されるデザインパターン（例えば、私は頻繁にあなたに、O（∩_∩）O〜ハハ要求されます）を、いくつかのデザインパターンを見つけ尋ねる何シングルトン友人、友人の工場）。この時点で、新人は何か大きなを見つけるために神にお願いいたします。
「偉大な神は、なぜ今、いくつかの面接官は、多くの場合、モードああを設計するように頼ま？」
「ルーキー、それはない、ああプログラミングで重要なデザインパターンがいっぱいです！」
「なぜ、？」
「デザインパターンは、前任者の経験を蓄積して良いの役割を果たし、スケーラビリティのための書き込みコードです。デザイン・パターンでは、我々は簡単に後から展開する、エレガントなコードを書くことができます。また、コードのデザインは良い、需要ある場合スケーラビリティ、ビューのR＆Dの点から、影響を拡張しませんあなたのコードの延長は、リスク回避を助長しました。」
「しかし、私はああデザインパターンの使用を見ていない、ほとんど私の同僚のコードを参照してください！
」
「私が唯一の言うことができる、あなたはSpringMVCを使用すると、ルーチンは、コントローラ、サービス、マッパー、エンティティの様々なを書くことですが、私たちだけ定義し、実装する必要があります。しかし、ほとんどの人はサービスにまだあるが、拡張メンテナンスを投稿するのは簡単、サービス肥大化を行うコードの大きな塊をしませ書くための関数（山法）に基づいており、読みやすさも比較的貧弱です。」
「されていないことを、私たちは、ああ、すべてそうです！」
「それについての良いデザインは、私たちは彼の同僚の後ろに行くことができないことをなぜあなたは簡単に拡張ニーズを達成することができ、あなたのコードを維持しています。」
「だからと言って、デザインパターンは、あなたがそれの工場モデルを教え、重要です。」
「まあ、私は人生はそれを学んだ教えてあげる!!」
「偉大な!!」
2.ファクトリメソッドパターン
、私たちは多くの場合、Factory Methodパターンを使用している、いわゆるオーソドックスファクトリメソッドは、それは一種の機能の何がありますか？
1、製品クラスは抽象クラスを継承するか（例えば、ここで私たちは車のインタフェースを実現）共通のインタフェースを実装します。
2、ファクトリクラスが実装するインターフェースは、インターフェースは、（一緒に実装され、当社の製品カーロックのインタフェースである我々のCarFactoryなど）共通の抽象製品クラスまたはインタフェースをサブクラス化することです。
図3に示すように、対応するオブジェクトのインスタンスを戻すために、等、文字列、列挙することによって、対応する製品タイプファクトリクラスを得ました。
/**
* @author Seig Heil
* @date 2019/5/30 21:30
* @desc 车接口
*/
public interface Car {
/**
* 获取名称
* @return
*/
String getName();
}
/**
* @author Seig Heil
* @date 2019/5/30 21:31
* @desc 奥迪车
*/
public class AudiCar implements Car {
@Override
public String getName() {
return "我是一辆奥迪车";
}
}
/**
* @author Seig Heil
* @date 2019/5/30 21:32
* @desc 宝马车
*/
public class BwmCar implements Car {
@Override
public String getName() {
return "我是一辆宝马车";
}
}
/**
* @author Seig Heil
* @date 2019/5/30 21:34
* @desc 车工厂接口
*/
public interface Factory {
/**
* 创建车
* @return
*/
Car create(Type type);
/**
* 车类型
*/
enum Type{
Audi,Bwm
}
}
/**
* @author Seig Heil
* @date 2019/5/30 21:33
* @desc 车工厂
*/
public class CarFactory implements Factory{
@Override
public Car create(Type type) {
switch (type){
case Audi:
return new AudiCar();
case Bwm:
return new BwmCar();
}
return null;
}
}
クライアントのテストクラス
/**
* @author Seig Heil
* @date 2019/5/30 21:40
* @desc
*/
public class Client {
public static void main(String[] args) {
CarFactory factory = new CarFactory();
Car audi = factory.create(Factory.Type.Audi);
System.out.println(audi.getName());
Car bwm = factory.create(Factory.Type.Bwm);
System.out.println(bwm.getName());
}
}
コンソール出力
我是一辆奥迪车
我是一辆宝马车
概要は、このファクトリメソッドパターンは、最も一般的な形式であり、それがために、「開閉原則」と一致していない製品カテゴリの増加場合である欠陥、我々はファクトリクラスを変更する必要があり、その後の道を、（持っています）延長にオープン、クローズ修正。
3. Abstract Factoryパターン
特性が要約される：（1）各製品ラインの排他的クラス工場、ファクトリインタフェースまたは抽象クラス、（2）、ファクトリインタフェースまたは抽象クラスのリターンパラメータは、製品の基本クラスまたはインタフェースです。
車両工場のインターフェイスを定義し、オブジェクトは、車のインタフェースを返すことです。
/**
* @author Seig Heil
* @date 2019/5/30 21:34
* @desc 车工厂接口
*/
public interface CarFactory {
/**
* 创建车
* @return
*/
Car create();
}
アウディとBMWは、それぞれ自分の工場を達成します
/**
* @description: 奥迪车工厂类
* @Date : 2019/8/6 下午4:37
* @Author : 石冬冬-Seig Heil
*/
public class AudiCarFactory implements CarFactory {
@Override
public Car create() {
return new AudiCar();
}
}
/**
* @description: 宝马车工厂类
* @Date : 2019/8/6 下午4:37
* @Author : 石冬冬-Seig Heil
*/
public class BwmCarFactory implements CarFactory {
@Override
public Car create() {
return new BwmCar();
}
}
テストクラスを書きます
/**
* @description: 测试类
* @Date : 2019/8/6 下午5:06
* @Author : 石冬冬-Seig Heil
*/
public class Client {
public static void main(String[] args) {
CarFactory audiCarFactory = new AudiCarFactory();
System.out.println(audiCarFactory.create().getName());
CarFactory bwmCarFactory = new BwmCarFactory();
System.out.println(bwmCarFactory.create().getName());
}
}
誘導：我々は製品の種類ごとに、上記の例から見ることができ、自分の工場があり、同じ製品をサブクラス化することができ、植物のさまざまな種類がとても拡張のために、抽象クラスにのみ、最上層またはインタフェースをしています新製品のカテゴリは、唯一の工場、工場とすることができ、対応する製品カテゴリを追加する必要があります。これは「開閉の原則」に沿ったものであるが、それはそれ以上のクラスを持っていますが、私たちはしばしば、この需要はほとんど実際のシーンを持っています。
4.静的ファクトリパターン
モデルのファクトリメソッド、我々は、ファクトリクラスが省略されたファクトリインタフェースを簡素化することができます。
/**
* @author Seig Heil
* @date 2019/5/30 21:46
* @desc 静态工厂实现
* 区别：
* （1）、工厂类无需实现接口
* （2）、提供静态方法调用
*/
public final class SimpleCarFactory {
/**
* 创建产品
* @param type
* @return
*/
public final static Car create(Type type){
switch (type){
case Audi:
return new AudiCar();
case Bwm:
return new BwmCar();
}
return null;
}
public static enum Type{
Audi,Bwm
}
private SimpleCarFactory(){}
}
私たちは、実際には、植物がもはやインターフェースを実装しますが、静的な方法を提供することにあることがわかっていない、Factory Methodパターンを比較して、それが思わリフレッシュがたくさん。
クライアントのテストクラス
/**
* @author Seig Heil
* @date 2019/5/30 21:40
* @desc
*/
public class Client {
public static void main(String[] args) {
Car audi = SimpleCarFactory.create(SimpleCarFactory.Type.Audi);
System.out.println(audi.getName());
Car bwm = SimpleCarFactory.create(SimpleCarFactory.Type.Bwm);
System.out.println(bwm.getName());
}
}
5.静的実装工場+を反射
これらの2つの実装、静的ファクトリメソッドパターンや工場パターンの両方を取って、私たちの製品を高めるために、製品の生産のための対応する処理は、（2が、我々は列挙を追加する必要があるかなどの）修正される必要があり、現時点では、使用することができます放射線。
/**
* @author Seig Heil
* @date 2019/5/30 21:46
* @desc 静态工厂实现
* 区别：
* （1）、工厂类无需实现接口
* （2）、提供静态方法调用
* （3）、通过反射实现，用户端只需要提供子类.class即可。
*/
public final class SimpleCarFactory {
/**
* 创建产品
* @param clazz
* @return
*/
public final static Car create(Class<? extends Car> clazz){
try {
return (Car)Class.forName(clazz.getName()).newInstance();
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
private SimpleCarFactory(){}
}
私たちは、メソッドは、クラス<？車を拡張>、それが簡単に着信クライアントの呼び出しをさせないように入ってくるのパラメータは、インターフェイスの車を実装しなければならないことを意味パラメータを定義するために採用されていることがわかります。
このようなクラスHondaCarとして。
/**
* @author Seig Heil
* @date 2019/5/30 21:56
* @desc 这辆车没有实现 Car接口
*/
public class HondaCar {
public String getName(){
return "我是一辆丰田车";
}
}
クライアントのテストクラス
/**
* @author Seig Heil
* @date 2019/5/30 21:40
* @desc
*/
public class Client {
public static void main(String[] args) {
Car audi = SimpleCarFactory.create(AudiCar.class);
System.out.println(audi.getName());
Car bwm = SimpleCarFactory.create(BwmCar.class);
System.out.println(bwm.getName());
Car honda = SimpleCarFactory.create(HondaCar.class);//这里一行代码其实是无法编译通过的
System.out.println(honda.getName());
}
}
上記によると、私たちは、という単純な工場+反射モード、用語の拡大、限り、製品のクラスが実装として車へのインタフェースを見ることができます。呼び出し側関係していることから、法令は厳密にパラメータを制御するために、車のインタフェースを実装する必要があり、静的メソッドのサブクラスを定義します。
6.列挙
別にこれら3から、列挙するのである1は、そこにあります。
特性が要約される：
1、列挙が抽象メソッドを定義し、戻り型は車共通インタフェースを実装する方法のサブクラスです。
図2に示すように、抽象メソッドを達成するために列挙体、およびオブジェクトインスタンスを返します。
図3は、用語の拡大から、新しいサブクラスはメンバーのみを追加し、抽象メソッドを実装する必要があります。
4、読み資するクライアントコールに「デメテルの原則」に従います。
/**
* @author Seig Heil
* @date 2019/5/30 22:05
* @desc 枚举方式实现
* （1）、定义一个抽象方法
* （2）、成员实现该抽象方法
* 从扩展性来讲：
* 1、增加一个产品类，需要增加一个枚举成员，相对静态工厂+反射方式，需要增加代码。
*/
public enum CarFactoryEnum {
Audi{
@Override
Car create() {
return new AudiCar();
}
},
Bwm{
@Override
Car create() {
return new BwmCar();
}
};
abstract Car create();
}
クライアントのテストクラス
/**
* @author Seig Heil
* @date 2019/5/30 21:40
* @desc
*/
public class Client {
public static void main(String[] args) {
Car audi = CarFactoryEnum.Audi.create();
System.out.println(audi.getName());
Car bwm = CarFactoryEnum.Bwm.create();
System.out.println(bwm.getName());
}
}
7.まとめ
私たちは、達成するために、これらの4つのメソッドを呼び出し、あなたは何を覚えていますか？あなたが感動していない場合は、自分自身の手のコードをノック。プログラマーとして、唯一のコードをよりノック、私たちは自分の理解を深めことができます。ただ、蒸しパンのような、他の人を見て、良いを行うには、それを自分を試してみてください。その後、バーに手を！
ファクトリモードは、最も一般的なタイプですが、私たちは、Springフレームワークを使用するには、ビーンビーンコンテナ管理に引き渡さオブジェクトを置くことができます。
我々は上記のいくつかのモデルを持っている場合にもかかわらず、それは同僚の間niubilityを吹くことができません。率直に言って、マスターを言えば、あなたが実際にプロジェクトを使用することができ、そのようなコードは、あなたが改善し続けたときに、時間をかけて、あなたは偉大な神となり、レベルではなく、一般市民が上昇するだろう。
同様に、クンは言った、「私はあなたが知っている、 『戻る』いくつかの書かれた言葉だろう？」
