【设计模式】简单工厂模式

简单工厂模式

简单工厂模式(Simple Factory Pattern)：定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。因为在简单工厂模式中用于创建实例的方法是静态(static)方法，因此简单工厂模式又被称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。

简单工厂模式并不属于GoF 23个经典设计模式，但通常将它作为学习其他工厂模式的基础，它的设计思想很简单，其基本流程如下：

1. 首先将需要创建的各种不同对象（例如各种不同的Chart对象）的相关代码封装到不同的类中，这些类称为具体产品类
2. 而将它们公共的代码进行抽象和提取后封装在一个抽象产品类中，每一个具体产品类都是抽象产品类的子类
3. 然后提供一个工厂类用于创建各种产品，在工厂类中提供一个创建产品的工厂方法，该方法可以根据所传入的参数不同创建不同的具体产品对象；
4. 客户端只需调用工厂类的工厂方法并传入相应的参数即可得到一个产品对象。

简单工厂模式的要点在于：**当你需要什么，只需要传入一个正确的参数，就可以获取你所需要的对象，而无须知道其创建细节。**简单工厂模式结构比较简单，其核心是工厂类的设计。

在简单工厂模式结构图中包含如下几个角色：

• Factory（工厂角色）：工厂角色即工厂类，它是简单工厂模式的核心，负责实现创建所有产品实例的内部逻辑；工厂类可以被外界直接调用，创建所需的产品对象；在工厂类中提供了静态的工厂方法factoryMethod()，它的返回类型为抽象产品类型Product。

• Product（抽象产品角色）：它是工厂类所创建的所有对象的父类，封装了各种产品对象的公有方法，它的引入将提高系统的灵活性，使得在工厂类中只需定义一个通用的工厂方法，因为所有创建的具体产品对象都是其子类对象。

• ConcreteProduct（具体产品角色）：它是简单工厂模式的创建目标，所有被创建的对象都充当这个角色的某个具体类的实例。每一个具体产品角色都继承了抽象产品角色，需要实现在抽象产品中声明的抽象方法。

实例：

某销售管理系统支持多种支付方式，如现金支付CashPay、信用卡支付CreditcardPay、现金券支付VoucherPay等，在设计中如果不使用简单工厂模式，可能会存在如下支付方法

public void pay(String type) {
    if ("cash".equels(type)) {
        // 现金支付方式的代码
    } else if ("creditcardPay".equals(type)) {
        // 信用卡支付方式代码
    }
    ...
}

这样的代码意味着代码冗余，而且当需要增加新的支付方式的时候，就需要去更改这段if...else...代码，这样就违背了开闭原则，同时代码越长表示这段代码越不容易维护。而且各种支付方式的业务逻辑全都在这个判断中，这样的耦合就会比较高

所以可以通过简单工厂模式对这段代码进行重构：

根据简单工厂模式的角色来分析：

• 抽象产品角色：根据业务分析，这些支付方式共同的特点就是支付这个行为，所以可以将这个行为抽取出来

  public abstract class AbstractPay {
      // 共同的支付行为方法
      public abstract void pay(); 
  }
  

• 具体产品角色：可根据支付方式进行分类

  public class CashPay extends AbstractPay {
      public void pay() {
          // 现金支付的业务逻辑代码
      }
  }
  public class CreditcardPay extends AbstractPay {
      public void pay() {
          // 信用卡支付的业务逻辑代码
      }
  }
  

  等等…

• 工厂角色：

  public class PayMethodFactory {
      public static AbstractPay getPayMenthod(String type) {
          if ("cash".equels(type)) {
          	// 现金支付
              return new CashPay()
      	} else if ("creditcardPay".equals(type)) {
          	// 信用卡支付
              return new CreditcardPay()
      	}
          ...
      }
  }
  

经过简单工厂模式重构后可以发现，系统中的类的个数增加了，但是每一种支付处理方式都封装在单独的类中，而且工厂类中只有简单的判断逻辑代码，不需要关心具体的业务处理逻辑，很好的满足了单一职责原则，而通过抽取抽象类，满足了开闭原则，这样后续如果想要增加新的支付方式，就只需要新增一个类，以及在工厂类中的判断逻辑中增加几行简单的代码就可以实现

简单工厂模式优缺点：

• 优点：
  • 工厂类包含必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的职责，而仅仅“消费”产品，简单工厂模式实现了对象创建和使用的分离。
  • 客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，对于一些复杂的类名，通过简单工厂模式可以在一定程度减少使用者的记忆量。
  • 通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。
• 缺点：
  • 由于工厂类集中了所有产品的创建逻辑，职责过重，一旦不能正常工作，整个系统都要受到影响。
  • 使用简单工厂模式势必会增加系统中类的个数（引入了新的工厂类），增加了系统的复杂度和理解难度。
  • 系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。
  • 简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。

在以下情况下可以考虑使用简单工厂模式：

1. 工厂类负责创建的对象比较少，由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。
2. 客户端只知道传入工厂类的参数，对于如何创建对象并不关心。