设计模式详解之工厂模式
作者：刘文慧
本文将着眼于工厂模式，从简单工厂模式、工厂方法模式和抽象工厂模式出发，展开学习和深入探讨。
一、概述
我们在进行软件开发时要想实现可维护、可扩展，就需要尽量复用代码，并且降低代码的耦合度，而设计模式就是一种可以提高代码可复用性、可维护性、可扩展性以及可读性的解决方案。
大家熟知的 23 种设计模式，可以分为创建型模式、结构型模式和行为型模式三大类。其中，创建型模式是对类的实例化过程进行抽象，从而将对象的创建和使用分离开。工厂模式属于创建型模式的范畴，本文将着眼于工厂模式，从简单工厂模式、工厂方法模式和抽象工厂模式出发，展开学习和深入探讨。
二、基本概念
工厂模式的核心思想就是把创建对象和使用对象解藕，由工厂负责对象的创建，而用户只能通过接口来使用对象，这样就可以灵活应对变化的业务需求，方便代码管理、避免代码重复。
假设我们在工作中需要将产品 a 升级为产品 A ，如果创建对象的工作是由用户来做，也就是用户通过 new a()的形式创建对象，那么为了应对新的产品升级需求，我们还需要找到所有相关代码并将它们改为 new A()，这对于淘宝下的很多庞大工程而言就是一项极为繁琐的工作；而通过应用工厂模式，将所有对象创建工作交由工厂管理时，我们就可以直接在工厂中将 return new a()改为 return new A()，用户仍然可以调用 factory.createProduct(）方法而无须更改原本的代码。这样工厂可以通过复用来减少重复代码量，并且用户无需关注创建对象的逻辑。
工厂模式在 Java 程序员的工作中可以说是无处不在：我们最常用的 Spring 就是一个 Bean 工厂，IOC 通过 BeanFactory 对 Bean 进行管理（可参考上面这张类图）；我们使用的日志框架 slf4j 使用了工厂方法模式；JDK 的 Calendar 使用了简单工厂模式……
下面本文将结合基本概念和具体示例来详细分析常用的几种工厂模式。
2.1 简单工厂模式
顾名思义，简单工厂模式是最简单的一种工厂模式，它定义了一个负责生产对象的工厂类，使用者可以根据不同参数来创建并返回不同子类，这些子类都共用一个接口（即父类）。
结构
简单工厂模式包含三种类，分别是抽象产品类、具体产品类、工厂类，下面分别对各类及它们之间的关系作进一步说明。
使用
有了上述的基本概念，我们将简单工厂模式的使用步骤概括为：
step1：创建抽象产品类，并为具体产品定义好一个接口；
step2：创建具体产品类，其通过接口来继承抽象产品类，同时也要定义计划生产的每一个具体产品；
step3：创建工厂类，其创建的静态方法可以对传入的不同参数做出响应；
step4：外界使用者就能调用工厂类的静态方法了，通过传入不同参数来创建不同具体产品类的实例。
下面以淘宝服装店铺的商品展示销售进行阐释，比如一个衬衫专卖店需要在淘宝上展示旗下商品，我们可以把所有衬衫都分别单独定义一个类，这样就可以随意添加或修改某一个新的衬衫类型，并使用 Fcatory 类来判断要创建哪一个衬衫类型的对象，即：先声明一个父类对象的变量，再根据用户输入的参数判断新建什么具体的衬衫类型对象。
代码实现
结果输出
UML 图
优缺点
优点
1）将对象的使用和创建过程分离开，实现解藕。客户端不需要关注对象是谁创建的、怎么创建的，只要通过工厂中的静态方法就可以直接获取其需要的对象。
2）将初始化实例的工作放到工厂里执行，代码易维护， 更符合面向对象的原则，做到面向接口编程，而不是面向实现编程。
缺点
1）工厂类中需要选择创建具体某个对象，所以一旦添加新产品则必须要对工厂中的选择逻辑进行修改，导致工厂逻辑过于复杂，违背开闭原则。
2）工厂类集合了所有实例（具体产品）的创建逻辑，一旦这个工厂不能正常工作，整个系统都会受到影响。
3）静态方法不能被继承和重写，会造成工厂角色无法形成基于继承的等级结构。
适用场景
具体产品类较少时，使用简单工厂模式可以实现生产者与消费者的分离，而且也不会在工厂类中设定太复杂的判断逻辑。
使用者只知道传入工厂类的参数，不关心如何创建对象的逻辑时。
2.2 工厂方法模式
结构
工厂方法模式包含四种类，分别是抽象产品类、具体产品类、抽象工厂类、具体工厂类，下面分别对各类以及它们之间的关系作进一步说明。
使用
根据上述概念，下面将抽象工厂模式的使用步骤概括如下：
step1：创建抽象工厂类，定义具体工厂的公共接口；
step2：创建抽象产品类，定义具体产品的公共接口；
step3：创建具体产品类（继承抽象产品类），定义生产的具体产品；
step4：创建具体工厂类（继承抽象工厂类），定义创建相应具体产品实例的方法；
step5：外界调用具体工厂类的方法，创建不同具体产品类的实例。
还是以淘宝店铺下的宝贝分类展示功能举例，假如该服装店除男款衬衫和女款衬衫外，还要新增一个衬衫类型如中性衬衫，按照简单工厂模式我们依然可以继承 Shirt 抽象父类，override 衬衫类型，然后在 Fcatory 中添加新分支，然而这样虽然扩展了衬衫类型，却对 Fcatory 类进行了修改，不符合“开放扩展、关闭修改”的开闭原则。为了应对这种需求变化，我们可以使用工厂方法模式，提取出一个工厂父类接口 Fcatory，并创建各衬衫类型的工厂子类 WomenShirtFactory、MenShirtFactory、NeutralShirtFactory，并分别使用对应的工厂子类来判断要创建哪一衬衫类型的对象。
代码实现
结果输出
UML 图
优缺点
优点
1）符合开闭原则。新增一种产品时，只需要增加相应的具体产品类和工厂子类即可，可方便的生产或切换产品，而无须像简单工厂模式那样修改工厂类的判断逻辑，具有更高的扩展性 。
2）符合单一职责原则。每个具体工厂类只负责创建对应的具体产品，而简单工厂中的工厂类存在复杂的 switch 逻辑判断。
3）相比于简单工厂模式，使用的不是静态方法，可形成基于继承的等级结构。
缺点
1）一个具体工厂只能创建一种具体产品。添加新产品时，除增加新产品类外，还要提供与之对应的具体工厂类，类的个数成对增加，在一定程度上增加了系统复杂度；同时有更多的类需要编译和运行，给系统带来额外开销。
2）由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度，且在实现时可能需要用到 DOM、反射等技术，增加了系统的实现难度。
3）虽然保证了工厂方法内的对修改关闭，但对于使用工厂方法的类，如果要更换另外一种产品，仍然需要修改实例化的具体工厂类。
4）难以对父类接口进行修改，因为一旦修改接口，就必须要对众多的帮忙子类进行修改。
适用场景
一个类不确定它所必须创建的对象的类。在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可。
你期望获得较高的扩展性。
一个类希望由它的子类来指定它所创建的对象。在工厂方法模式中，对于抽象工厂类只需提供一个创建产品的接口，而由其子类来确定具体要创建的对象，利用面向对象的多态性和里氏替换原则，在程序运行时，子类对象将覆盖父类对象，从而使系统更容易扩展。
当类将创建对象的职责委托给多个工厂子类的中的某一个，且用户知道将要使用哪一个工厂子类。
2.3 抽象工厂模式
抽象工厂模式，提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们的具体类。抽象工厂模式与工厂方法模式最大的区别：抽象工厂中每个具体工厂可以创建多类具体产品；而工厂方法每个具体工厂只能创建一类具体产品。
结构
工厂方法模式包含五种类，分别是抽象产品族类、抽象产品类、具体产品类、抽象工厂类、具体工厂类，下面分别对各类以及它们之间的关系作进一步说明：
使用
根据上述概念，下面将工厂方法模式的使用步骤概括如下：
step1：创建抽象工厂类，定义具体工厂的公共接口；
step2：创建抽象产品族类，定义抽象产品的公共接口；
step3：创建抽象产品类（继承抽象产品族类），定义具体产品的公共接口；
step4：创建具体产品类（继承抽象产品类），定义生产的具体产品；
step5：创建具体工厂类（继承抽象工厂类），定义创建相应具体产品实例的方法；
step6：外界调用具体工厂类的方法，创建不同具体产品类的实例。
这里继续以网店销售服装举例，假设上述衬衫淘宝专卖店的运营总部还有一家裤子淘特专卖店，随着用户需求变化，淘宝用户也要购买裤子，同时淘特用户要购买衬衫，那么我们可以使用抽象工厂模式升级这两个店铺，令淘宝店铺展示销售衬衫+裤子，淘特店铺展示销售裤子+衬衫。
代码实现
结果输出
UML 图
优缺点
优点
1）降低耦合度。抽象工厂模式将具体产品的创建延迟到具体工厂类中，这样将对象的创建封装起来，可以减少客户端与具体产品类之间的依赖，从而降低系统耦合度，有利于后期的维护和扩展。
2）符合开闭原则。新增一种产品类时，只需增加相应的具体产品类和工厂子类即可，简单工厂模式需要修改工厂类的判断逻辑。
3）符合单一职责原则。每个具体工厂类只负责创建对应的产品，简单工厂模式中的工厂类需要进行复杂的 switch 逻辑判断。
4）不使用静态工厂方法，可以形成基于继承的等级结构。
5）便于添加更换产品族。因为具体产品都是由具体工厂创建的，所以在更换产品族的时候只要简单修改具体工厂即可。
6）具体产品的创建过程和客户端隔离。客户端通过操作抽象产品接口实现操作具体产品实例，具体产品的类名不会出现在客户端中。
缺点
1）难以支持新种类产品的变化。这是因为抽象工厂接口中已经确定了可被创建的产品集合，如果需要添加新产品，此时就必须去添加抽象产品接口，还要在抽象工厂接口中添加新方法，并在所有具体工厂中实现该新方法。这样就会改变抽象工厂类以及所有具体工厂子类的改变，违背开闭原则。
2）类图有点复杂，可读性没有工厂方法模式高。
适用场景
系统不要求依赖产品类实例如何被创建、组合和表达，这点也是所有工厂模式应用的前提。
系统要求提供一个产品类的库，所有产品以同样的接口出现，客户端不需要依赖具体实现。
系统中有多个产品族，但每次只使用其中某一族产品。（切换产品族只需修改具体工厂对象即可）
三、总结
简单工厂模式：让一个工厂类负责创建所有对象；但没有考虑后期扩展和维护，修改违背开闭原则，静态方法不能被继承。
工厂方法模式：主要思想是继承，修改符合开闭原则；但每个工厂只能创建一种类型的产品。
抽象工厂模式：主要思想是组合，本质是产品族，实际包含了很多工厂方法，修改符合开闭原则；但只适用于增加同类工厂这种横向扩展需求，不适合新增功能方法这种纵向扩展。
其实这三种工厂模式在形式和特点上都非常相似，甚至存在一定的内在联系，而且最终目的都是解耦。在使用时，我们不必去在意这个模式到底工厂方法模式还是抽象工厂模式，因为它们之间也是可以灵活转变的。
比如你原本使用的是工厂方法模式，加入一个新方法后就可能会让具体产品类构成不同等级结构中的产品族，代码结构就变成抽象工厂模式了；而对于抽象工厂模式，当减少一个或多个具体产品类时，使原有产品族只剩下一个产品后，代码结构也就转变成了工厂方法模式。
版权声明: 本文为 InfoQ 作者【阿里技术】的原创文章。
原文链接:【http://xie.infoq.cn/article/4b8e7ce446d58c79337a476c3】。文章转载请联系作者。
专注分享阿里技术的丰富实践和前沿创新。 2022-05-24 加入
阿里技术的官方号，专注分享阿里技术的丰富实践、前沿洞察、技术创新、技术人成长经验。阿里技术，与技术人一起创造成长与成就。
评论