带你读《2022技术人的百宝黑皮书》——浅析设计模式1 —— 工厂模式（4）

带你读《2022技术人的百宝黑皮书》——浅析设计模式1 —— 工厂模式（3）

https://developer.aliyun.com/article/1262282?groupCode=taobaotech

抽象工厂模式

抽象工厂模式，提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们的具体类。抽象工厂模式与工厂 方法模式最大的区别：抽象工厂中每个具体工厂可以创建多类具体产品；而工厂方法每个具体工厂只能创建一类具体产品。  

结构

工厂方法模式包含五种类，分别是抽象产品族类、抽象产品类、具体产品类、抽象工厂类、具体工厂类，下面分别 对各类以及它们之间的关系作进一步说明：

使用

根据上述概念，下面将工厂方法模式的使用步骤概括如下：

1. step1：创建抽象工厂类，定义具体工厂的公共接口；

2. step2：创建抽象产品族类，定义抽象产品的公共接口；

3. step3：创建抽象产品类（继承抽象产品族类），定义具体产品的公共接口；

4. step4：创建具体产品类（继承抽象产品类），定义生产的具体产品；

5. step5：创建具体工厂类（继承抽象工厂类），定义创建相应具体产品实例的方法；

6. step6：外界调用具体工厂类的方法，创建不同具体产品类的实例。

这里继续以网店销售服装举例，假设上述衬衫淘宝专卖店的运营总部还有一家裤子淘特专卖店，随着用户需求变 化，淘宝用户也要购买裤子，同时淘特用户要购买衬衫，那么我们可以使用抽象工厂模式升级这两个店铺，令淘宝 店铺展示销售衬衫+裤子，淘特店铺展示销售裤子+衬衫。

代码实现

//step1:创建抽象工厂类，定义具体工厂的公共接口
public abstract class Factory{
 public abstract Clothing ExhibitShirt();
 public abstract Clothing ExhibitTrousers();
}
//step2:创建抽象产品族类，定义抽象产品的公共接口
public abstract class Clothing{
public abstract void Show();
}
//step3:创建抽象产品类，定义具体产品的公共接口
//女装抽象类
public abstract class Shirt extends Clothing{
 @Override
 public abstract void Show();
}
//男装抽象类
public abstract class Trousers extends Clothing{
 @Override
 public abstract void Show();
}
//step4:创建具体产品类（继承抽象产品类），定义生产的具体产品
//衬衫产品类A，淘宝衬衫
public class TBShirt extends Shirt{
 @Override
 public void Show(){
 System.out.println("展示淘宝店铺衬衫");
}
//衬衫产品类B，淘特衬衫
public class TTShirt extends Shirt{
 @Overside
 public void Show(){
 System.out.println("展示淘特店铺衬衫")；
 }
}
//裤子产品类A，淘宝裤子
public class TBTrousers extends Trousers{
 @Override
 public void Show(){
 System.out.println("展示淘宝店铺裤子");
 }
}
//裤子产品类B，淘特裤子
public class TTTrousers extends Trousers{
 @Overside
 public void Show(){
 System.out.println("展示陶特店铺裤子")；
  }
}
//step5:创建具体工厂类，定义创建具体产品实例的方法
//淘宝工厂类A，展示衬衫+裤子
public class TBFactory extends Factory{
 @Overside
 public Clothing ExhibitShirt(){
 return new TBShirt()；
 }
 @Overside
 public Clothing ExhibitTrousers(){
 return new TBTrousers()；
 }
}
//淘特工厂类B，展示裤子+衬衫
public class TTFactory extends Factory{
 @Overside
 public Clothing ExhibitShirt(){
 return new TTShirt()；
 }
 @Overside
 public Clothing ExhibitTrousers(){
 return new TTTrousers()；
 }
}
//step6:外界实例化具体工厂类，调用工厂类中创建不同目标产品的方法，创建不同具体产品类的实例
public class AbstractFactoryPattern{
 public static void main(String[] args){
 TBFactory exhibitTBFactory = new TBFactory();
 TTFactory exhibitTTFactory = new TTFactory();
 //淘宝用户搜索衬衫
 exhibitTBFactory.ExhibitShirt().Show();
 //淘宝用户搜索衬衫
 exhibitTBFactory.ExhibitTrousers().Show();
 //淘特用户搜索衬衫
 exhibitTTFactory.ExhibitShirt().Show();
 //淘特用户搜索衬衫
 exhibitTTFactory.ExhibitTrousers().Show();
 }
}

结果输出

展示淘宝店铺衬衫
展示淘宝店铺裤子
展示淘特店铺衬衫
展示淘特店铺裤子

UML图

优缺点

优点

1.降低耦合度。抽象工厂模式将具体产品的创建延迟到具体工厂类中，这样将对象的创建封装起来，可以减少客户 端与具体产品类之间的依赖，从而降低系统耦合度，有利于后期的维护和扩展。

2.符合开闭原则。新增一种产品类时，只需增加相应的具体产品类和工厂子类即可，简单工厂模式需要修改工厂类 的判断逻辑。 符合单一职责原则。每个具体工厂类只负责创建对应的产品，简单工厂模式中的工厂类需要进行复杂的 switch 逻辑判断。

3.不使用静态工厂方法，可以形成基于继承的等级结构。

4.便于添加更换产品族。因为具体产品都是由具体工厂创建的，所以在更换产品族的时候只要简单修改具体工厂即 可。

5.具体产品的创建过程和客户端隔离。客户端通过操作抽象产品接口实现操作具体产品实例，具体产品的类名不会 出现在客户端中。

缺点

1. 难以支持新种类产品的变化。这是因为抽象工厂接口中已经确定了可被创建的产品集合，如果需要添加新产品，  此时就必须去添加抽象产品接口，还要在抽象工厂接口中添加新方法，并在所有具体工厂中实现该新方法。这样  就会改变抽象工厂类以及所有具体工厂子类的改变，违背开闭原则。

2. 类图有点复杂，可读性没有工厂方法模式高。  

适用场景

1. 系统不要求依赖产品类实例如何被创建、组合和表达，这点也是所有工厂模式应用的前提。 2. 系统要求提供一个产品类的库，所有产品以同样的接口出现，客户端不需要依赖具体实现。 3. 系统中有多个产品族，但每次只使用其中某一族产品。（切换产品族只需修改具体工厂对象即可）

总结

简单工厂模式：让一个工厂类负责创建所有对象；但没有考虑后期扩展和维护，修改违背开闭原则，静态方法不能 被继承。

工厂方法模式：主要思想是继承，修改符合开闭原则；但每个工厂只能创建一种类型的产品。 抽象工厂模式：主要思想是组合，本质是产品族，实际包含了很多工厂方法，修改符合开闭原则；但只适用于增加 同类工厂这种横向扩展需求，不适合新增功能方法这种纵向扩展。

其实这三种工厂模式在形式和特点上都非常相似，甚至存在一定的内在联系，而且最终目的都是解耦。在使用时， 我们不必去在意这个模式到底工厂方法模式还是抽象工厂模式，因为它们之间也是可以灵活转变的。比如你原本使 用的是工厂方法模式，加入一个新方法后就可能会让具体产品类构成不同等级结构中的产品族，代码结构就变成抽 象工厂模式了；而对于抽象工厂模式，当减少一个或多个具体产品类时，使原有产品族只剩下一个产品后，代码结 构也就转变成了工厂方法模式。

下篇内容预告：除了工厂模式，策略模式也是程序员在工作实践中使用较多的设计模式，前者是创建型模式，后者 是行为型模式。这两种不同类型的设计模式，在某些地方也有相似之处；甚至在某些场景下结合使用时，还能起到 很好的效果。那么具体是哪些地方具有相似之处、哪些场景可以结合使用呢？下一篇文章将对设计模式中的策略模 式进行展开学习和讨论，敬请期待！

团队介绍

我们是大聚划算技术团队。

使命：让货品和心智运营变得高效且有确定性！

愿景：与运营、产品合力，打造最具价格优惠心智的购物入口，最具爆发性的营销矩阵。

职责：负责支持聚划算、百亿补贴、天天特卖等业务。我们聚焦优惠和选购体验，通过数智化驱动形成更有效率和确定性的货品运营方法论，为消费者提供精选和极致性价比的商品，为商家提供更具爆发确定性的营销方案。

这是一支极具业务 sense，又具备复杂业务系统架构和设计经验的团队。