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

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

需求:给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);
    }
}

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