JAVA设计模式之工厂模式(持续更新)

设计模式简介

​ 设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理地运用设计模式可以完美地解决很多问题，每种模式在现实中都有相应的原理来与之对应，每种模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是设计模式能被广泛应用的原因。

设计模式的类型

​ 根据设计模式的参考书 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素） 中所提到的，总共有 23 种设计模式。这些模式可以分为三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns）。当然，我们还会讨论另一类设计模式：J2EE 设计模式

序号	模式 & 描述	包括
1	创建型模式 这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。	· 工厂模式（Factory Pattern）· 抽象工厂模式（Abstract Factory Pattern）· 单例模式（Singleton Pattern）· 建造者模式（Builder Pattern）· 原型模式（Prototype Pattern）
2	结构型模式 这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。	· 适配器模式（Adapter Pattern）· 桥接模式（Bridge Pattern）· 过滤器模式（Filter、Criteria Pattern）· 组合模式（Composite Pattern）· 装饰器模式（Decorator Pattern）· 外观模式（Facade Pattern）· 享元模式（Flyweight Pattern）· 代理模式（Proxy Pattern）
3	行为型模式 这些设计模式特别关注对象之间的通信。	· 责任链模式（Chain of Responsibility Pattern）· 命令模式（Command Pattern）· 解释器模式（Interpreter Pattern）· 迭代器模式（Iterator Pattern）· 中介者模式（Mediator Pattern）· 备忘录模式（Memento Pattern）· 观察者模式（Observer Pattern）· 状态模式（State Pattern）· 空对象模式（Null Object Pattern）· 策略模式（Strategy Pattern）· 模板模式（Template Pattern）· 访问者模式（Visitor Pattern）
4	J2EE 模式 这些设计模式特别关注表示层。这些模式是由 Sun Java Center 鉴定的。	· MVC模式（MVC Pattern）· 业务代表模式（Business Delegate Pattern）· 组合实体模式（Composite Entity Pattern）· 数据访问对象模式（Data Access Object Pattern）· 前端控制器模式（Front Controller Pattern）· 拦截过滤器模式（Intercepting Filter Pattern）· 服务定位器模式（Service Locator Pattern）· 传输对象模式（Transfer Object Pattern）

下面用一个图片来整体描述一下设计模式之间的关系：

设计模式的六大原则

1、开闭原则（Open Close Principle）

开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。

2、里氏代换原则（Liskov Substitution Principle）

里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

3、依赖倒转原则（Dependence Inversion Principle）

这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。

4、接口隔离原则（Interface Segregation Principle）

这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。

5、迪米特法则，又称最少知道原则（Demeter Principle）

最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。

6、合成复用原则（Composite Reuse Principle）

合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。

工厂模式

工厂模式（Factory Pattern）是 Java 中最常用的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。

在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。

介绍

意图： 定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。

主要解决： 主要解决接口选择的问题。

何时使用： 我们明确地计划不同条件下创建不同实例时。

如何解决： 让其子类实现工厂接口，返回的也是一个抽象的产品。

关键代码： 创建过程在其子类执行。

应用实例： 1、您需要一辆汽车，可以直接从工厂里面提货，而不用去管这辆汽车是怎么做出来的，以及这个汽车里面的具体实现。 2、Hibernate 换数据库只需换方言和驱动就可以。3、Spring中只需要知道Bean的Id就可以获取到对应的bean对象(通过BeanFactory创建)

优点： 1、一个调用者想创建一个对象，只要知道其名称就可以了。 2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。 3、屏蔽产品的具体实现，调用者只关心产品的接口。

缺点： 每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。

使用场景： 1、日志记录器：记录可能记录到本地硬盘、系统事件、远程服务器等，用户可以选择记录日志到什么地方。 2、数据库访问，当用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时。 3、设计一个连接服务器的框架，需要三个协议，“POP3”、“IMAP”、“HTTP”，可以把这三个作为产品类，共同实现一个接口。

注意事项： 作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过 new 就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。

实现

下面例子中鼠标，键盘，耳麦为产品，惠普，戴尔为工厂

简单工厂模式

简单工厂模式不是 23 种里的一种，简而言之，就是有一个专门生产某个产品的类。

比如下图中的鼠标工厂，专业生产鼠标，给参数 0，生产戴尔鼠标，给参数 1，生产惠普鼠标。

为鼠标创建一个接口。

public interface Mouse {
    //自我介绍的方法
    void sayHi();
}

创建实现接口的实体类。

DellMouse.java

public class DellMouse implements Mouse {
    @Override
    public void sayHi() {
        System.out.println("我是戴尔公司生产的鼠标");
    }
}

HpMouse.java

public class HpMouse implements Mouse {
    @Override
    public void sayHi() {
        System.out.println("我是惠普公司生产的鼠标");
    }
}

创建一个工厂，生成基于给定信息的实体类的对象。

MouseFactory.java

public class MouseFactory {
    public static Mouse createMouse(int i){
        Mouse mouse = null;
        switch (i){
            case 0:
                mouse = new DellMouse();
                break;
            case 1:
                mouse = new HpMouse();
                break;
        }
        return mouse;
    }
}

使用该工厂，通过传递类型信息来获取实体类的对象。

Main

public class Main {
    public static void main(String[] args) {
        Mouse mouse = MouseFactory.createMouse(0);
        mouse.sayHi();

        mouse = MouseFactory.createMouse(1);
        mouse.sayHi();
    }
}

执行程序，输出结果：

我是戴尔公司生产的鼠标
我是惠普公司生产的鼠标

根据简单工厂的定义，用户只要产品而不在乎产品如何生产，看起来好像很完美的样子。但大家想想，这个世界存在什么都生产的工厂吗？

显然是不存在的，每一种鼠标都有自己的生产工厂，都有自己生产技术。映射到spring框架中，我们有很多很多种的bean需要生产，如果只依靠一个简单工厂来实现，那么我们得在工厂类中嵌套多少个if…else if啊？

而且我们在代码中生产一个鼠标只是new一下就出来了，但实际操作中却不知道需要进行多少操作，加载、注册等操作都将体现在工厂类中，那么这个类就会变得紊乱，管理起来也很不方便，所以说每个品牌应该有自己的生产类。

因为专一，所以专业嘛，这个时候工厂方法就出现了。

工厂模式

工厂模式也就是鼠标工厂是个父类，有生产鼠标这个接口。

戴尔鼠标工厂，惠普鼠标工厂继承它，可以分别生产戴尔鼠标，惠普鼠标。

生产哪种鼠标不再由参数决定，而是创建鼠标工厂时，由戴尔鼠标工厂创建。

后续直接调用鼠标工厂.生产鼠标()即可

根据上述代码可以看出，不同品牌的鼠标是由不同的工厂生产的，貌似又是很完美的。但大家看一下测试类，当一个人想要去买一个戴尔鼠标的时候（假设没有销售商），那么他就要去找戴尔工厂给他生产一个，过几天又想要买一个惠普鼠标的时候，又得跑到惠普工厂请人生产，这无疑就增加了用户的操作复杂性。所以有没有一种方便用户操作的方法呢？这个时候抽象工厂模式就出现了。

抽象工厂模式

抽象工厂模式也就是不仅生产鼠标，同时生产键盘。

也就是 PC 厂商是个父类，有生产鼠标，生产键盘两个接口。

戴尔工厂，惠普工厂继承它，可以分别生产戴尔鼠标+戴尔键盘，和惠普鼠标+惠普键盘。

创建工厂时，由戴尔工厂创建。

后续工厂.生产鼠标()则生产戴尔鼠标，工厂.生产键盘()则生产戴尔键盘。

在抽象工厂模式中，假设我们需要增加一个工厂

假设我们增加华硕工厂，则我们需要增加华硕工厂，和戴尔工厂一样，继承 PC 厂商。

之后创建华硕鼠标，继承鼠标类。创建华硕键盘，继承键盘类即可。

在抽象工厂模式中，假设我们需要增加一个产品

假设我们增加耳麦这个产品，则首先我们需要增加耳麦这个父类，再加上戴尔耳麦，惠普耳麦这两个子类。

之后在PC厂商这个父类中，增加生产耳麦的接口。最后在戴尔工厂，惠普工厂这两个类中，分别实现生产戴尔耳麦，惠普耳麦的功能。 以上。

根据上述代码可以看出，用户需要一个产品，只需要去找PC工厂提出自己的需求，便能得到自己想要产品，而不用根据产品去寻找不同的生产工厂，方便用户操作。

按我粗浅的理解，设计模式的经典之处，就在于解决了编写代码的人和调用代码的人双方的痛楚，不同的设计模式也只适用于不同的场景。至于用或者不用，如何使用，那就需要我们根据具体的业务和实际情况进行分析了

总结

一、一句话概括工厂模式
​ 简单工厂：一个工厂类，一个产品抽象类。
​ 工厂方法：多个工厂类，一个产品抽象类。
​ 抽象工厂：多个工厂类，多个产品抽象类。
二、生活中的工厂模式
​ 简单工厂类：一个麦当劳店，可以生产多种汉堡。
​ 工厂方法类：一个麦当劳店，可以生产多种汉堡。一个肯德基店，也可以生产多种汉堡。
​ 抽象工厂类：百胜餐饮集团下有肯德基和百事公司，肯德基生产汉堡，百事公司生成百事可乐。

有疑问可以一起加群讨论