【一天一个设计模式】——工厂模式

为了提升自身编写代码的风格规约，打算学一学恼人的设计模式，今天从工厂设计模式开始~

工厂模式属于创建型设计模式，也是比较常用的设计模式之一，从字面意思，我们就可以知道它是用来创建对象的一个工厂，那么我们何时去选择使用这一设计模式呢？

设计思想
我们通过创建一个接口，让其实现类根据相应的条件有选择的创建对象，而不对外暴露出具体创建过程，外部只知道调用了接口，而不知道对象是如何创建的。

例子
从上面我们可以知道，这样的结构使代码之间的耦合度降低，提高了代码的可重用性，方便测试、修改和扩展，举个例子：

在一个电商项目，物流系统包括了航空物流、陆上物流和海上物流，在不同情况下需要根据需要调用不同的物流方式

项目结构为

——src
 ——main
  ——java
   ——com.xxx.demo.logis
    ——service
     ——impl
      ——AviationLogisticsServiceImpl
      ——MarineLogisticsServiceImpl
      ——OnshoreLogisticsServiceImpl
     ——LogisticsService
    ——logisticsFactory
 ——test
  ——java
   ... ...

首先创建一个接口LogisticsService，要想创建3种物流方式，都需要通过这个接口来处理。

public interface LogisticsService {
   void getLogistic(各种参数);
}

接下来创建实现接口的实体类AviationLogisticsServiceImpl、MarineLogisticsServiceImpl、OnshoreLogisticsServiceImpl。这些类中需要实现具体的业务，你可以看到，每个实现类互不干扰，这对未来业务的维护很友善，若将来想添加新的物流方式，例如“无人机物流”，那么只需要按照相似的结构编写业务逻辑即可。

public class AviationLogisticsServiceImpl implements LogisticsService {
 
   @Override
   public void getLogistic(各种参数) {
      具体业务逻辑...
   }
}

public class OnshoreLogisticsServiceImpl implements LogisticsService {
 
   @Override
   public void getLogistic(各种参数) {
      具体业务逻辑...
   }
}

public class MarineLogisticsServiceImpl implements LogisticsService {
 
   @Override
   public void getLogistic(各种参数) {
      具体业务逻辑...
   }
}

最后创建一个工厂Factory，生成基于给定信息的实体类对象。这里的给定信息，我们假设当传入的参数Lcode为10301时，生成航空物流；参数为10302时，生成海上物流，参数为10303时，生成陆上物流。

public class logisticsFactory {
    
   //使用 getLogis 方法获取物流类型的对象
   public LogisticsService getLogis(String Lcode){
      if(Lcode == null){
         return null;
      }        
      if(Lcode.equals("10301")) return new AviationLogisticsServiceImpl();
      if(Lcode.equals("10302")) return new MarineLogisticsServiceImpl();
	  if(Lcode.equals("10303")) return new OnshoreLogisticsServiceImpl();
      throw new RuntimeException("此物流方式不存在")
   }
}

在工厂中，你可以根据相应的条件来创建对象，若以后增加了新的物流，可以到这里进行修改。

总结：

在工厂模式中，每个实体类都只关心自己的业务逻辑，都只有一个功能，这满足了单一职责原则，同时调用者在创建对象时无需了解具体创建流程，避免了与业务逻辑发生碰撞，最后，工厂模式的扩展性好，但不宜加入过多的“产品”。