现实业务场景中的工厂类使用

首先先说说一下业务场景,系统属于电子商务系统,向前对接各种第三方渠道,为渠道提供相应的接口服务。
向后对接的是公司的核心系统,向后对接的系统校验规则已经很多年了,没办法进行重构,成本太高。
为了管理向前的渠道代码，以及区分每个渠道的自定义的开发需求。项目中主要运用了工厂类的开发模式。

需求:给A,B渠道同步当月成交记录,给渠道B,C同步当月退费记录,给渠道A,C同步当月投诉记录。
首先先区分渠道A,B,C,D,E这种现实中存在的机构,分别作为独立的实现类来用。
 

@Service
public class ChannelA implements DoneService,ComplainService {

    @Override
    public void done(String params) {
        //todo 实现成交
    }

    @Override
    public void complain(String params) {
        //todo 实现投诉
    }
}


@Service
public class ChannelB implements DoneService,RefundService {

    @Override
    public void refund(String params) {
        //todo 实现退费
    }

    @Override
    public void done(String params) {
        //todo 实现成交
    }
}

@Service
public class ChannelC implements ComplainService,RefundService {


    @Override
    public void refund(String params) {
        //todo 实现退费
    }

    @Override
    public void complain(String params) {
        //todo 实现投诉
    }
}

然后就是对应的需求部分,也可以理解为行为部分,也可以认为是性格部分,我比较喜欢将整体的代码看做是
每一个人的和行为的组装，上述的渠道可以看做是独立的人,而像这种可变的需求理解为不同的性格。
成交记录好比是性格开朗,退费好比是郁郁寡欢等等。。。。
在java中,这种性格的东西一般表现形式为接口类,成千上万的人的性格无非就是几大类,上帝让谁有哪种性格，
去实现它就好。
 

public interface ComplainService {

    /**
     * 投诉接口
     * @param params
     */
    void complain(String params);
}

public interface DoneService {

    /**
     * 成交接口
     * @param params
     */
    void done(String params);
}

public interface RefundService {

    /**
     * 退费接口
     * @param params
     */
    void refund(String params);
}

下面就是工厂类的开发,工厂类顾名思义就是将不同的性格安装到不同的人身上的地方,每一个性格都要有独立的工厂,
这样才不至于在造性格的时候出现混乱,要么开朗,要么沉闷,那有人说了有的人本身就有双重人格怎么办,没问题有啥性格
就去实现啥.
 

public class ComplainFactory {

    public static ComplainService getRefundService(String channelCode){
        if("A".equals(channelCode)){
            return SpringContextUtils.getBean(ChannelA.class);
        }else if ("C".equals(channelCode)){
            return SpringContextUtils.getBean(ChannelC.class);
        }else{
            return null;
        }
    }
}



public class DoneFactory {

    public static DoneService getDoneService(String channelCode){
     if("A".equals(channelCode)){
         return SpringContextUtils.getBean(ChannelA.class);
     }else if ("B".equals(channelCode)){
         return SpringContextUtils.getBean(ChannelB.class);
     }else{
         return null;
     }
    }

}


public class RefundFactory {

    public static RefundService getRefundService(String channelCode){
        if("B".equals(channelCode)){
            return SpringContextUtils.getBean(ChannelB.class);
        }else if ("C".equals(channelCode)){
            return SpringContextUtils.getBean(ChannelC.class);
        }else{
            return null;
        }
    }
}

最后就是根据每个人的名字不同,来判断是哪一个工厂类进行性格的养成。
 

 public static void main(String[] args) {

        String channlCode="";//渠道code
        String params="";//需要同步的数据

        DoneService doneService=DoneFactory.getDoneService(channlCode);
        if (null != doneService) {  //成交接口
            doneService.done(params);
        }

        RefundService refundService= RefundFactory.getRefundService(channlCode);
        if (null != refundService) { //退费接口
            refundService.refund(params);
        }

        ComplainService complainService = ComplainFactory.getRefundService(channlCode);
        if (null != complainService) { //投诉接口
            complainService.complain(params);
        }
    }

这种设计模式虽然开始的时候,搭建相对复杂.但是这种模式减少了后续的重复开发工作,再有新的渠道的话,可以直接新建
渠道类然后根据不同的接口实现即可。
最后按照规矩应该挂自己的公众号啥的,不过还没有呢,哈哈先这样吧。