1.1简单工厂模式
1.1.1看一个具体的需求：看一个披萨的项目：要便于披萨种类的扩展，要便于维护

• 披萨的种类很多(比如 GreekPizz、CheesePizz 等)
• 披萨的制作有 prepare，bake, cut, box
• 完成披萨店订购功能。

1.1.2使用传统的方式来完成

• 思路分析(类图)
  

package pattern.factory;public class OrderPizza {private SimpleFactory factory;public OrderPizza(SimpleFactory factory) {this.factory = factory;}public OrderPizza(String Type) {Pizza pizza = null;if (Type.equals("greek")) {pizza = new GreekPizza();pizza.setName(" 希腊披萨 ");} else if (Type.equals("cheese")) {pizza = new CheesePizza();pizza.setName(" 奶酪披萨 ");} else if (Type.equals("pepper")) {pizza = new PepperPizza();pizza.setName("胡椒披萨");}//输出 pizza 制作过程pizza.prepare();pizza.bake();pizza.cut();pizza.box();}private String getType() {return null;}}
public class PepperPizza extends Pizza {}public class CheesePizza extends Pizza {}public class GreekPizza extends Pizza {}

public class Pizza {private String name;public void setName(String s) {}public void prepare() {}public void bake() {}public void cut() {}public void box() {}
}

1.1.3传统的方式的优缺点

• 优点是比较好理解，简单易操作。
• 缺点是违反了设计模式的 ocp 原则，即对扩展开放，对修改关闭。即当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码.
• 比如我们这时要新增加一个 Pizza 的种类(Pepper 披萨)，我们需要做如下修改. 如果我们增加一个 Pizza 类，只要是订购 Pizza 的代码都需要修改.

结论

• 我们要去找到变化的地方进行抽取，在改动的时候只需要改动抽取的地方就可以，如下图是变化的地方
  
• 如果增加一个pizza种类就要多加一个类型，那我们不妨抽取出来，将这些if，抽象成只是一个制作pizza的步骤，比如createPizza(),而如何制作pizza的，则是我们抽取的部分。

1.1.4改进的思路分析

• 分析：修改代码可以接受，但是如果我们在其它的地方也有创建 Pizza 的代码，就意味着，也需要修改，而创建 Pizza
  的代码，往往有多处。
• 思路：把创建 Pizza 对象封装到一个类中，这样我们有新的 Pizza 种类时，只需要修改该类就可，其它有创建到 Pizza
  对象的代码就不需要修改了.-> 简单工厂模式

1.2使用简单工厂模式

• 简单工厂模式的设计方案: 定义一个可以实例化 Pizaa 对象的类，封装创建对象的代码。

public class SimpleFactory {//更加 orderType 返回对应的 Pizza 对象public Pizza createPizza(String orderType) {Pizza pizza = null;System.out.println("使用简单工厂模式");if (orderType.equals("greek")) {pizza = new GreekPizza();pizza.setName(" 希腊披萨 ");} else if (orderType.equals("cheese")) {pizza = new CheesePizza();pizza.setName(" 奶酪披萨 ");} else if (orderType.equals("pepper")) {pizza = new PepperPizza();pizza.setName("胡椒披萨");}return pizza;}
}

1.3工厂方法模式
1.3.1看一个新的需求

• 披萨项目新的需求：客户在点披萨时，可以点不同口味的披萨，比如 北京的奶酪 pizza、北京的胡椒 pizza 或者是伦敦的奶酪 pizza、伦敦的胡椒 pizza。

  • 思路 1

    • 使用简单工厂模式，创建不同的简单工厂类，比如 NYPizzaFactory、ChicogoPizzaFactory 等等.从当前这个案例来说，也是可以的，但是考虑到项目的规模，以及软件的可维护性、可扩展性并不是特别好
      
      

  • 思路 2
    使用工厂方法模式
    1.3.2工厂方法模式介绍

    • 工厂方法模式设计方案：将披萨项目的实例化功能抽象成抽象方法，在不同的口味点餐子类中具体实现。
    • 工厂方法模式：定义了一个创建对象的抽象方法，由子类决定要实例化的类。工厂方法模式将对象的实例化推迟到子类。
      1.3.3工厂方法模式应用案例
    • 披萨项目新的需求：客户在点披萨时，可以点不同口味的披萨，比如 北京的奶酪 pizza、北京的胡椒 pizza 或者是伦敦的奶酪 pizza、伦敦的胡椒 pizza
    • UML图解方案
      

//OrderPizza.java 类import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import com.atguigu.factory.factorymethod.pizzastore.pizza.Pizza;
public abstract class OrderPizza {//定义一个抽象方法，createPizza ,  让各个工厂子类自己实现abstract Pizza createPizza(String orderType);// 构造器public OrderPizza(){Pizza pizza = null;String orderType; //  订购披萨的类型orderType = getType();pizza = createPizza(orderType); //抽象方法，由工厂子类完成//输出 pizza 制作过程pizza.prepare(); pizza.bake();pizza.cut();pizza.box();}// 写一个方法，可以获取客户希望订购的披萨种类private String getType(){try{BufferedReader strin = new BufferedReader(new InputStreamReader(System.in));System.out.println("input pizza 种类:");String str = strin.readLine();return str;}catch(IOException e){e.printStackTrace(); return "";}}
}
public class BJOrderPizza extends OrderPizza {@OverridePizza createPizza(String orderType) {Pizza pizza = null;if(orderType.equals("cheese")){pizza = new BJCheesePizza();}else if(orderType.equals("pepper")){pizza = new BJPepperPizza();}}
}
public class LDOrderPizza extends OrderPizza {@OverridePizza createPizza(String orderType) {Pizza pizza = null;if(orderType.equals("cheese")){pizza = new LDCheesePizza();} else if(orderType.equals("pepper")){pizza = new LDPepperPizza();}}
}

1.4抽象工厂模式
1.4.1基本介绍

• 抽象工厂模式：定义了一个 interface 用于创建相关或有依赖关系的对象簇，而无需指明具体的类
• 抽象工厂模式可以将简单工厂模式和工厂方法模式进行整合。
• 从设计层面看，抽象工厂模式就是对简单工厂模式的改进(或者称为进一步的抽象)。
• 将工厂抽象成两层，AbsFactory(抽象工厂) 和 具体实现的工厂子类。程序员可以根据创建对象类型使用对应的工厂子类。这样将单个的简单工厂类变成了工厂簇，更利于代码的维护和扩展。
• 类图

1.4.2抽象工厂模式应用实例:使用抽象工厂模式来完成披萨项目.

//一个抽象工厂模式的抽象层(接口) public interface AbsFactory {//让下面的工厂子类来 具体实现public Pizza createPizza(String orderType);
}
//这是工厂子类
public class BJFactory implements AbsFactory{@Overridepublic Pizza createPizza(String orderType) {System.out.println("~使用的是抽象工厂模式~");Pizza pizza = null;if(orderType.equals("cheese")){pizza = new BJCheesePizza();}else if(orderType.equals("pepper")){pizza = new BJPepperPizza();}return pizza;}
}
public class LDFactory implements AbsFactory {@Overridepublic Pizza createPizza(String orderType){System.out.println("~使用的是抽象工厂模式~");Pizza pizza = null;if (orderType.equals("cheese")){pizza = new LDCheesePizza();}else if (orderType.equals("pepper")){pizza = new LDPepperPizza();}return pizza;}
}
//OrderPizza.java
public class OrderPizza {AbsFactory factory;// 构造器public OrderPizza(AbsFactory factory){setFactory(factory);}private void setFactory(AbsFactory factory){Pizza pizza = null;String orderType = ""; //  用户输入this.factory = factory;orderType = getType();// factory  可能是北京的工厂子类，也可能是伦敦的工厂子类pizza = factory.createPizza(orderType);if (pizza != null){// 订 购 okpizza.prepare();pizza.bake();pizza.cut();pizza.box();} else {System.out.println("订购失败"); break;}}// 写一个方法，可以获取客户希望订购的披萨种类private String getType(){try{BufferedReader strin = new BufferedReader(new InputStreamReader(System.in)); System.out.println("input pizza 种类:");String str = strin.readLine();return str;}catch(IOException e){e.printStackTrace();return "";}}
}

总结

简单工厂

那么再用另一个实例总结一下，根据简单工厂之前的那段代码，其实就是我们每个人会去写的最普通的代码，而到了简单工厂模式，就是有一大类的pizza，然后分好几种pizza，然后由一个工厂去制作，说一个案例就是我们要开一个饭馆，我们有面条

反例

public class negtive {/*===============服务端======================*/interface Food{void eat();}static class Noodles implements Food{@Overridepublic void eat() {System.out.println("吃面条。。。。。");}}/*=================客户端===================*/public static void main(String[] args) {Food food01 = new Noodles();food01.eat();}
}

UML类图

这时候，产品来改需求来了，“哥，你先把刀放下。咱们现在这 Noodles改名了，得改个特牛逼的名字Spaghetti，让用户记住咱们这是西餐意大利面。”

这时候，因为你原有设计是上面的反例，你得能从修改服务端的源代码开始，再修改客户端源代码。以后再有改名这类事，你还要把刀拿出来放桌上给产品看。

这种设计过于脆弱，因为这样服务端源代码和客户端源代码是耦合的，改变会牵一发而动全身。

改成如下就可

public class postive {/*===============服务端======================*/interface Food{void eat();}static class Spaghetti implements Food {@Overridepublic void eat() {System.out.println("吃西餐面条。。。。。");}}static class FoodFactory {public Food getFood(int num){Food food =null;switch (num){case 1 :food = new Spaghetti();}return food;}}/*=================客户端===================*/public static void main(String[] args) {FoodFactory foodFactory = new FoodFactory();Food food01 = foodFactory.getFood(1);food01.eat();}
}

UML类图

通过这样一个正例，把创建对象的代码全交给服务端处理，将服务端代码和客户端代码进行了解耦。以后产品再找你聊天是不是可以暂时把刀收起来了？

这样做的好处，不只是服务端开发人员受益，当服务端代码修改时，客户端也不知道，也不需要知道。这样的设计模式并不是十全十美的，任何一种设计模式都不会是十全十美的。只是根据业务逻辑在各方面进行取舍。

## 简单工厂模式的缺点：

客户必须记住工厂中常量和具体产品的映射关系。一旦产品品种体量增大到一定程度，工厂类将变得非常臃肿。最致命的缺陷，增加产品时，就要修改工厂类。违反开闭原则。

---

工厂方法模式

• 简述：为了进行扩展，不违反开闭原则。这里是基于简单工厂模式进行改进。
• 正例

public class postive {/*===============服务端======================*///-----------------------产品--------------------interface Food{void eat();}static class Spaghetti implements Food {@Overridepublic void eat() {System.out.println("吃西餐面条。。。。。");}}//新增产品static class Rice implements Food {@Overridepublic void eat() {System.out.println("吃米饭。。。。。");}}//--------------------------工厂-----------------------interface FoodFactory {Food getFood();}static class SpaghettiFactory implements FoodFactory{@Overridepublic Food getFood() {return new Spaghetti();}}//新增产品工厂static class RiceFactory implements FoodFactory{@Overridepublic Food getFood() {return new Rice();}}/*=================客户端===================*/public static void main(String[] args) {FoodFactory foodFactory = new  SpaghettiFactory();Food food01 = foodFactory.getFood();food01.eat();}
}

• 针对简单工厂违反开闭原则的这一缺陷，工厂方法模式进行优化。可以看到此时再去增加产品，不再需要修改工厂类，而是增加相应的产品类和工厂类即可。这是符合开闭原则的。

这里就会有聪明的小问号有很多朋友了：

• 如果源代码作者修改相关工厂类的类名，那这时候调用工厂类的客户端代码就需要修改了，这不如简单工厂呢？

  • 首先这里要明确一个概念，工厂类在实际使用中，是相当于接口类的，接口类一般不允许进行修改（非必须），工厂类作者有责任，有义务保证工厂类的类名是稳定的，也就是说，工厂类是比产品类更加稳定的。

• 既然使我们后面自己扩展的Rice类，为什么不直接实例化它，直接使用。我们就是作者，为什么不能直接使用？

  • 这里需要扩展一下，有时候一个产品类并不是孤立的，它和其他类一起组成一个服务框架。

• 那么如何扩展呢，如下：

 /*===============服务端======================*/     //------------------------产品质检流程-----------------------、static class QualityInspection {public void checking(FoodFactory foodFactory){System.out.println("我是人肉质检员。。。。。准备开吃 -_- ");Food food = foodFactory.getFood();food.eat();}}/*=================客户端===================*/public static void main(String[] args) {FoodFactory foodFactory01 = new  SpaghettiFactory();FoodFactory foodFactory02 = new  RiceFactory();QualityInspection inspection = new QualityInspection();inspection.checking(foodFactory02);inspection.checking(foodFactory01);

总体来说就是增加一个制作东西的工厂，再增加要制作的东西的类，实现以及继承就能实现扩展

UML类图

这时候，如果Rice没有他的工厂类，甚至都没办法参加质检，那还怎么卖？

• 所以编写工厂类并不只是单纯为了实例化某些产品类，而是能让配套服务通过工厂接口，得以调用工厂创建产品实例。

有的小朋友大大的眼睛里还有疑惑：那为什么QualityInspection的checking方法不直接调用Food接口再进行产品的实例化呢？

• 这时候回到简单工厂模式，产品类不同于工厂类，它是善变的，它会随着需求的变化而变化，这时候，直接依赖产品类的各种方法，将需要被修改，违反开闭原则。这是死路，小朋友别杠了。哈哈哈。

当然，工厂方法模式也是有缺陷的：

• 当业务需要的类型变多，目前只有食物，当产生饮料，日用品等类别时，我们又要创建新的工厂来实现，造成代码重复臃肿。

抽象工厂模式

针对工厂方法模式的缺陷，抽象工厂模式将进行改进，一个工厂负责创建一个产品簇的对象。
关于产品簇：是指多个存在内在联系的或者存在逻辑关系的产品。如图所示

简述：在抽象工厂模式中，接口是负责创建一个相关对象的工厂，不需要显式指定它们的类。每个生成的工厂都能按照工厂模式提供对象。

抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。

在这里换一个例子，那就是我们我们要生产6号螺母以及8号螺母，对应着6号螺丝以及8号螺丝，这就出现了两类产品，两类工厂。代码如下

public class postive {/*===============服务端======================*///-----------------------产品--------------------/*----------------螺丝---------------------*/interface Screw{void createScrew();}static class Screw_06 implements Screw {@Overridepublic void createScrew() {System.out.println("create Screw_06 666666。。。。。");}}static class Screw_08 implements Screw {@Overridepublic void createScrew() {System.out.println("create Screw_08 8888888。。。。。");}}/*----------------螺母---------------------*/interface Nut{void createNut();}static class Nut_06 implements Nut {@Overridepublic void createNut() {System.out.println("create Nut_06 666666。。。。。");}}static class Nut_08 implements Nut {@Overridepublic void createNut() {System.out.println("create Nut_08 8888888。。。。。");}}//--------------------------工厂-----------------------interface ComponentsFactory {Screw getScrew();Nut getNut();}/*----------------6号工厂---------------------*/static class Factory_666 implements ComponentsFactory {@Overridepublic Screw getScrew() {return new Screw_06();}@Overridepublic Nut getNut() {return new Nut_06();}}/*----------------8号工厂---------------------*/static class Factory_888 implements ComponentsFactory {@Overridepublic Screw getScrew() {return new Screw_08();}@Overridepublic Nut getNut() {return new Nut_08();}}//------------------------产品质检流程-----------------------、static class QualityInspection {public void checking(ComponentsFactory Factory){System.out.println("我是人肉质检员。。。。。等待产出零件 -_- ");Screw screw = Factory.getScrew();Nut nut = Factory.getNut();screw.createScrew();nut.createNut();System.out.println("开始质检.......");System.out.println("      ");}}/*=================客户端===================*/public static void main(String[] args) {ComponentsFactory Factory01 = new   Factory_666();ComponentsFactory Factory02 = new   Factory_888();QualityInspection inspection = new QualityInspection();inspection.checking(Factory01);inspection.checking(Factory02);}
}

UML类图

可以看到，如果在需要进行一种N号螺丝或者螺母的扩展，只需要增加一个实现N号螺丝或者螺母接口的产品类，利用一个新增N号工厂进行创建即可。

可以看到，抽象工厂仍然保持着简单工厂模式和工厂方法模式的优点：

• 服务端代码和客户端代码是低耦合的。（简单工厂模式）
• 所有这一切动作都是新增，不是修改，符合开闭原则。

还新增了一个特有的优点：

• 抽象工厂有效减少了工厂的数量，一个工厂就生产同一个产品簇的产品。
  这下产品来改需求，是不是还可以笑嘻嘻跟他聊会天了？

再次强调，一个抽象工厂负责创建同一个产品簇的对象。而产品簇是指多个存在内在联系的或者存在逻辑关系的产品。也就是6号工厂只生产6号的零部件，不负责生产8号零部件。不能不同产品簇的产品混合到一个工厂中进行生产。

缺陷：当增加产品簇时（增加6 、 8号螺帽的生产），这时候就要修改以前工厂（6 、 8号工厂）的源代码了。

总结就是：

当产品簇比较固定时，考虑使用抽象工厂。
当产品簇经常变动时，不建议使用抽象工厂。

故而如下：
工厂方法模式：
一个抽象产品类，可以派生出多个具体产品类。
一个抽象工厂类，可以派生出多个具体工厂类。
每个具体工厂类只能创建一个具体产品类的实例。
抽象工厂模式：
多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。
一个抽象工厂类，可以派生出多个具体工厂类。
每个具体工厂类可以创建多个具体产品类的实例。
区别：
工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。
工厂方法模式的具体工厂类只能创建一个具体产品类的实例，而抽象工厂模式可以创建多个。

设计模式(三)--工厂模式相关推荐

1. 设计模式之工厂模式（三）

   上一次我们已经通过代码,简单的认识了工厂方法模式,具体的思路请移步到设计模式之工厂模式(二),进行查看.这次,让我们通过设计模式的思想,来好好认识下工厂方法模式. 创建者和产品 所有工厂模式都用来封装 ...

2. JavaScript设计模式--简单工厂模式例子---XHR工厂

   JavaScript设计模式--简单工厂模式例子---XHR工厂 第一步,Ajax操作接口(目的是起一个接口检测作用) (1)引入接口文件 //定义一个静态方法来实现接口与实现类的直接检验 //静态方 ...

3. 三角形圆形创建与擦除java_设计模式---------------简单工厂模式

   设计模式---------------简单工厂模式 一.题目(Question) 使用简单工厂模式设计一个可以创建不同几何形状(如圆形.方形和三角形等)的绘图工具,每个几何图形都要有绘制draw()和 ...

4. Java 设计模式之工厂模式（二）

   原文地址:Java 设计模式之工厂模式(二) 博客地址:http://www.extlight.com 一.背景 本篇内容是 Java 设计模式创建型模式的第二篇.上一篇主题为 <Java 设计 ...

5. php工厂模式和单例模式,php 设计模式之工厂模式、单例模式、注册树模式

   php 设计模式之工厂模式.单例模式.注册树模式 在软件工程中,创建型设计模式承担着对象创建的职责,尝试创建适合程序上下文的对象,对象创建设计模式的产生是由于软件工程设计的问题,具体说是向设计中增加复 ...

6. 教你如何一篇博客读懂设计模式之—--工厂模式

   一篇博客读懂设计模式之-工厂模式 工厂模式在我们日常开发的时候经常用到,相信大家都有了一定的了解,工厂模式是一种创建对象的设计模式,它提供一种创建对象的最佳方式. 主要过程是: 定义一个创建对象的接口 ...

7. 系统架构技能之设计模式-抽象工厂模式

   一.上篇回顾 上篇我们主要讲述了简单工厂模式和工厂模式.并且分析了每种模式的应用场景和一些优缺点,我们现在来回顾一下: 简单工厂模式:一个工厂负责所有类型对象的创建,不支持无缝的新增新的类型对象的创建 ...

8. java设计模式之工厂模式(UML类图分析+代码详解)

   大家好,我是一名在算法之路上不断前进的小小程序猿!体会算法之美,领悟算法的智慧~ 希望各位博友走过路过可以给我点个免费的赞,你们的支持是我不断前进的动力!! 加油吧!未来可期!! 本文将介绍java设 ...

9. java 设计模式 路由器_java设计模式2————工厂模式

   java设计模式2----工厂模式 1.工厂模式介绍: 1.1.实现了创建者与调用者的分离 1.2.详细分类: 简单工厂模式 工厂方法模式 抽象工厂模式 1.3.所遵循的OOP原则: 开闭原则:对扩展 ...

最新文章

1. 5.3Role和Claims授权「深入浅出ASP.NET Core系列」
2. 映入眼帘的JSON-fastjson常见用法
3. Linux10-归档、系统间复制文件
4. mysql 左连接 例子_mysql左连接自连接例子
5. timestamp 字段
6. Halcon：区域特征：select_shape(Regions : SelectedRegions : Features, Operation, Min, Max : )
7. phpmyadmin的安装部署
8. angularJS中，怎么阻止事件冒泡
9. unity快捷放置物体操作
10. cacti php zombie,Cacti1.2.x新版教程之监控本机
11. mysql 异常笔记
12. transformClassesWithProfilers-transformForDebug
13. java多个文件压缩成zip文件
14. Cocos2dx中Lua游戏性能优化指南
15. sigmod 函数与softmax 函数对比
16. Java学习笔记-IO
17. 《深入理解分布式事务》，初识分布式......
18. 【iuap5.0特性解读】构建以业务创新和能力沉淀为核心的中台架构体系
19. 理解 RxSwift：为什么要使用 RxSwift（一）
20. GB2312的中文编码表

热门文章

1. 旋转协方差rot6d
2. Qt-OpenCV学习笔记--人脸识别
3. 数据结构PTA 案例6-1.5 旅游规划
4. pythonrandint用法_Python randint()用法及代码示例
5. 流化床锅炉水冷壁防磨格栅智链工艺
6. vue-router next(false) 禁止访问某个页面时，不保留历史访问记录
7. HTML5思维脑图插件推荐
8. vue 打包失败问题UglifyJs Unexpected token: name
9. C语言求边长500以内的毕达哥拉斯三元组的个数
10. 如何营造性能至上的团队文化