工厂模式

案例引进

• 需求：设计一个咖啡店点餐系统

• 具体的类图如下：

  设计一个咖啡类（Coffee），并定义其两个子类（美式咖啡【AmericanCoffee】和拿铁咖啡【LatteCoffee】）；再设计一个咖啡店类（CoffeeStore），咖啡店具有点咖啡的功能。

• 代码实现

  创建咖啡类（抽象类）以及具体的咖啡类

咖啡店提供点餐方法

模拟客户通过咖啡店点餐

• 存在的问题

  加入我们想要新增一种咖啡类型的话，那么就必须修改CoffeeStore这个类！这违反了开闭原则

在Java中，万物皆对象，这些对象都需要创建，如果创建的时候直接new该对象，就会对该对象耦合严重，假如我们要更换对象，所有new对象的地方都需要修改一遍，这显然违背了软件设计的开闭原则。如果我们使用工厂来生产对象，我们就只和工厂打交道就可以了，彻底和对象解耦，如果要更换对象，直接在工厂里更换该对象即可，达到了与对象解耦的目的；所以说，工厂模式最大的优点就是：解耦。

• 三种工厂模式

  • 简单工厂模式（非23种经典设计模式）
  • 工厂方法模式
  • 抽象工厂模式

简单工厂模式

• 简单工厂不是一种设计模式，反而比较像是一种编程习惯。

• 结构

  • 抽象产品 ：定义了产品的规范，描述了产品的主要特性和功能。
  • 具体产品 ：实现或者继承抽象产品的子类
  • 具体工厂 ：提供了创建产品的方法，调用者通过该方法来获取产品。
• 使用简单工厂模式修改咖啡店案例

  将生产咖啡的方法放进简单工厂中

这样的话，在咖啡店类里面已经不依赖具体的咖啡产品对象了！

也就是解除了咖啡店和具体的产品对象之间的依赖！

后续新增咖啡类型也只需要在工厂中新增即可

• 优点

  • 封装了创建对象的过程，可以通过参数直接获取对象。
  • 把对象的创建和业务逻辑层分开，这样以后就避免了修改客户代码，如果要实现新产品直接修改工厂类，而不需要在原代码中修改，这样就降低了客户代码修改的可能性，更加容易扩展。

• 缺点

  • 增加新产品时还是需要修改工厂类的代码，违背了“开闭原则”。
• 静态工厂

  将工厂中生产产品的方法使用static进行修饰

工厂方法模式

• 为了解决简单工厂模式中的违反开闭原则的缺点，可以使用工厂方法模式

• 概念

  • 定义一个用于创建对象的接口，让子类决定实例化哪个产品类对象。工厂方法使一个产品类的实例化延迟到其工厂的子类。

• 结构（相比简单工厂多了一个抽象工厂）

  • 抽象工厂（Abstract Factory）：提供了创建产品的接口，调用者通过它访问具体工厂的工厂方法来创建产品。
  • 具体工厂（ConcreteFactory）：主要是实现抽象工厂中的抽象方法，完成具体产品的创建。
  • 抽象产品（Product）：定义了产品的规范，描述了产品的主要特性和功能。
  • 具体产品（ConcreteProduct）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它同具体工厂之间一一对应。
• 实现

  类图

新增抽象工厂和具体的产品工厂

调用的时候传入具体的工厂来获取具体的产品

从以上的编写的代码可以看到，要增加产品类时也要相应地增加工厂类，不需要修改工厂类的代码了，这样就解决了简单工厂模式的缺点。

工厂方法模式是简单工厂模式的进一步抽象。由于使用了多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。

• 优点

  • 用户只需要知道具体工厂的名称就可得到所要的产品，无须知道产品的具体创建过程；
  • 在系统增加新的产品时只需要添加具体产品类和对应的具体工厂类，无须对原工厂进行任何修改，满足开闭原则；

• 缺点

  • 无疑，每增加一种产品，都需要增加具体的产品工厂类以及具体的产品类，系统的复杂度提示明显。

抽象工厂模式

• 前面介绍的工厂方法模式中只生产同一种类型的产品（咖啡）。称为同等级产品

• 但是现实中还有许多工厂是综合工厂，可以生产多种类型的产品，称为同一个产品族（也可理解为同一个品牌）

• 抽象工厂模式将考虑多等级产品的生产，将同一个具体工厂所生产的位于不同等级的一组产品称为一个产品族，比如，苹果工厂生产苹果电脑和苹果手机

• 概念

  • 是一种为访问类提供一个创建一组相关或相互依赖对象的接口，且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品的模式结构。
  • 抽象工厂模式是工厂方法模式的升级版本，工厂方法模式只生产一个等级的产品，而抽象工厂模式可生产多个等级的产品。

• 结构

  • 抽象工厂（Abstract Factory）：提供了创建产品的接口，它包含多个创建产品的方法，可以创建多个不同等级的产品。
  • 具体工厂（Concrete Factory）：主要是实现抽象工厂中的多个抽象方法，完成具体产品的创建。
  • 抽象产品（Product）：定义了产品的规范，描述了产品的主要特性和功能，抽象工厂模式有多个抽象产品。
  • 具体产品（ConcreteProduct）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它 同具体工厂之间是多对一的关系。
• 实现

  现咖啡店业务发生改变，不仅要生产咖啡还要生产甜点，如提拉米苏、抹茶慕斯等，要是按照工厂方法模式，需要定义提拉米苏类、抹茶慕斯类、提拉米苏工厂、抹茶慕斯工厂、甜点工厂类，很容易发生类爆炸情况。

其中拿铁咖啡、美式咖啡是一个产品等级，都是咖啡；提拉米苏、抹茶慕斯也是一个产品等级；拿铁咖啡和提拉米苏是同一产品族（也就是都属于意大利风味），美式咖啡和抹茶慕斯是同一产品族（也就是都属于美式风味）。所以这个案例可以使用抽象工厂模式实现。类图如下：

现场见抽象产品类和具体产品类

然后创建抽象工厂和具体工厂

抽象工厂里面生产两种类型：一种是咖啡一种是甜点，这表示同一个等级

而具体工厂里面，生产的是同一产品族的不同等级的产品

如果要新增一个产品族的话（eg：中国风味），只需要新增一个对应的工厂类和对应的产品即可

• 优点

  • 当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。

• 缺点

  • 当产品族中需要增加一个新的产品时，所有的工厂类都需要进行修改。eg：下午茶新增一个汉堡，那么不仅需要增加具体的产品和抽象的产品；同时还需要修改抽象工厂和具体工厂（这里具体工厂也需要增加生产汉堡的方法，但是这里是不是违背了接口隔离原则？比如我只想生产咖啡和甜点，抽象工厂是不是需要实现接口隔离）

• 使用场景

  • 当需要创建的对象是一系列相互关联或相互依赖的产品族时，如电器工厂中的电视机、洗衣机、空调等。
  • 系统中有多个产品族，但每次只使用其中的某一族产品。如有人只喜欢穿某一个品牌的衣服和鞋。
  • 系统中提供了产品的类库，且所有产品的接口相同，客户端不依赖产品实例的创建细节和内部结构。

模式扩展

简单工厂+配置文件解除耦合

• 前面说的简单工厂的缺点就是：当新增一种产品的时候，需要修改工厂方法

• 可以通过工厂模式+配置文件的方式解除工厂对象和产品对象的耦合。在工厂类中加载配置文件中的全类名，并创建对象进行存储，客户端如果需要对象，直接进行获取即可。如果需要新增产品，直接在配置文件中添加即可

  定义配置文件，里面存储的是产品类，后续需要新增产品的话，只需要在配置文件中添加即可

在CoffeeFactory中，通过反射的方式创建配置文件中的对象并进行存储

在生产咖啡的时候，直接从Map中取出来

JDK源码-Collection.iterator方法

• 分析Collection的iterator方法

  

查看实现iterator方法的实现类

抽象商品

具体商品