设计模式之工厂模式

心得： 粗暴的开发方式而可以归纳为三步：定义属性，创建方法，调用展示。

工厂模式又称简单工厂模式，是创建型设计模式的一种。提供了按需创建对象的最佳方式，同时不会对外暴露创建细节，通过统一的接口创建对象。

优点

解耦：将对象的创建和使用进行分离

可复用：对于创建过程比较复杂且在很多地方都使用到的对象，通过工厂模式可以提高对象创建的代码的复用性。

降低成本：由于复杂对象通过工厂进行统一管理，所以只需要修改工厂内部的对象创建过程即可维护对象，从而达到降低成本的目的。

缺点

违背了开闭原则，每次增加一个类，都要去修改工厂类。

举例

在一个聚合支付系统中，有微信支付，支付宝支付，云闪付支付。通过传一个值来进行支付下单的需求，怎么去实现这个需求了？

不经思考我们可能会这样写：

 if (type.equals("weiXinPay")){
          //这里实现微信支付的相关代码

      }else if (type.equals("aliPay")){
          //这里实现支付宝支付的相关代码
      }else if (type.equals("UnionPay")){
          //这里实现云闪付支付的相关代码
      }

但我们支付系统在重新接了支付渠道，如作为银行的支付渠道。我们一直在else if （）里面添加。及其不同意扩展。

优化代码之后

我们设置了一个支付基类 ： PayService 里面有 doPay() 支付的方法 。

public interface PayService {

    /**
     *
     * @param payInfo  支付的入参
     * @return PayOutInfo 支付的出参
     */

    PayOutInfo doPay(PayInfo payInfo);
}

然后实现三个实体类，分别去实现PayService这个方法，然后重写里面的doPay（）；

定义一个工厂工具类

 PayService getPayService(PayInfo payInfo){
        if (payInfo.getType().equals("weiXinPay")){
            return new WxPayServiceImpl();

        }else if (payInfo.getType().equals("aliPay")){
            return new AliPayServiceImpl();
           
        }else if (payInfo.getType().equals("UnionPay")){
          return  new UnionPayServiceImpl();
        }
        return null;
    }

这样以后在加支付渠道，只需要在重新实现支付的基类，然后重写他的方法。但是需要修改工厂类。