对于代码写到一定地步，肯定会遇到很多业务代码的繁琐的if else分支。简单的几个条件可以if else几个，但是一旦后面的条件越来越多，有没有更好的替代让代码看起来没那么臃肿。更好维护，而不是一个if一个if的看过去。
其实是有的，就是工厂模式加策略模式来替代成坨的if else。
一 设计模式理解
首先来分析一下主要用到的两个设计模式
工厂模式：实际上工厂模式写法很多，比如说根据产品还是工厂方法来区分简单工厂和工厂方法模式。
根据工厂的抽象程度可分为工厂方法模式和抽象工厂模式。用于封装和管理对象的创建，是一种创建型模式。
//简单工厂模式
//首先你要有一个工厂，这个工厂实际上有很多流水线，每个流水线做不同的产品：比如手机和平板
public class Factory {
public Phone make(String type) {
if(phoneType.equalsIgnoreCase("Phone")){
return new Phone();
}
else if(phoneType.equalsIgnoreCase("Ipad")) {
return new Ipade();
}
return null;
}
}
//第二步，定义流水线（抽象的，流水线要用到方法）
public interface Equipment{
void make();
}
//第三步，是流水线来具体实施每个产品流水线的方法（这个是实现具体的）
public class Phone implements Equipment{
public Phone () {
this.make();
}
@Override
public void make() {
// TODO Auto-generated method stub
System.out.println("make phone 智能手机 !");
}
}
public class Ipad implements Equipment{
public Ipad () {
this.make();
}
@Override
public void make() {
// TODO Auto-generated method stub
System.out.println("make ipad 平板电脑!");
}
}
我们今天用到的其实有点像是简单工厂模式，就是工厂是一个，但是生产的产品是不同的，对比的是工厂方法模式，工厂接口，多个工厂继承工厂接口，每个工厂其实调用的方法相同但是各自实现完全不同
参照一下这个文章关于工厂模式的
设计模式工厂模式
策略模式
说句实在话，策略模式和工厂模式的抽象工厂方法挺像的。
对比就是策略模式里面有策略角色和具体策略角色，对比抽象工厂是抽象工厂和具体工厂。但是有一个context上下文来维护具体策略角色的实现
这个有个博客不错可以看一下
策略模式介绍
//抽象的策略
public abstract class Strategy {
//算法方法
public abstract void algorithmInterface();
}
//具体实现的策略，毕竟光抽象不行，还要给各个情况具体的策略
public class ConcreteStrategyA extends Strategy {
@Override
public void algorithmInterface() {
System.out.println("策略A实现");
}
}
public class ConcreteStrategyB extends Strategy {
@Override
public void algorithmInterface() {
System.out.println("策略B实现");
}
}
//上下文context，用来维护策略，实际要访问具体的策略要从context中获取
public class Context {
Strategy strategy;
public Context(Strategy strategy) {
this.strategy = strategy;
}
//上下文接口
public void contextInterface() {
strategy.algorithmInterface();
}
}
//使用的时候创建有具体策略的上下文
public class Client {
public static void main(String[] args) {
Context context;
context = new Context(new ConcreteStrategyA());
context.contextInterface();
context = new Context(new ConcreteStrategyB());
context.contextInterface();
context = new Context(new ConcreteStrategyC());
context.contextInterface();
}
}
二 使用工厂模式+策略模式来替代if else
前面讲到了工厂模式和策略模式是什么，大概的写法（工厂模式写的肯定不全，可以看一下我链接的文章来看一下更多的工厂方式，其实相当于同一个操作提供给更多实现方式，来适应不同的情况）
实际上，就是利用工厂模式生成管理不同的策略（在这一步，工厂类特别像策略模式里面的上下文环境context），定好策略（这个跟抽象工厂方法很像，但是又有很大不同，抽象工厂加一个方法，所有的实现的方法具体工厂都要实现，但是利用了策励模式就不同，工厂只管管理调用方法，真正要用到的都是策励来提供），然后实现不同的具体策略
可以这么说，策励模式解决了一个工厂模式的问题，“我有的，你们实现的都要有”，现在工厂只是提供一个使用策略的方法，不关心你制定多少个策略，每个策励有多少实现。解耦的同时，还做到开-闭原则：对扩展开放，对修改关闭
具体例子：
光说不练假把式，我这里是根据不同的操作查询资产来限制资产是否可以展出，有问题会给个错误码，同样也会把资产数据返回。
（1）创建工厂
工厂维护策略模式，以及具体实现的策略模式的注册，注册后的策略存在一个维护策略的map里面，适用工厂直接通过type类型作为code值来获取策略map里面的策略。
public class ValidAssetByTypeFactory {
private static Map<String,ValidateAssetService> validAssetTypeMap = new HashMap<>();
/**
* 用来维护根据类型验证资产的规则的map
* @param type
* @return
*/
public static ValidateAssetService getInvokeStrategyMap(String type){
return validAssetTypeMap.get(type);
}
/**
* 注册（创建实现类直接注册即可，不需要在该类放进策略map里面）
* @param type
* @param validateAssetService
*/
public static void register(String type, ValidateAssetService validateAssetService){
if(StringUtil.isEmpty(type)||null == validateAssetService){
return;
}
validAssetTypeMap.put(type,validateAssetService);
}
}
（2）创建策略
这个就直接解耦工厂模式的，“我有你们都要有“。策励是一个接口，具体策略就是实现这个接口，在策略模式里面，可以直接获取实现的具体策略。
注意点就是这个 extends InitializingBean不能少，全靠这个往工厂类里面的静态map里面塞值呢。
以下是一个例子，实际上肯定会有很多实现的具体策略。
/**
* 关于扫码验证资产的策略接口
* @Author: zhangpeng
* @Date: 2021/9/9 13:49
*/
public interface ValidateAssetService extends InitializingBean {
Result<List<DetailsAppAsset>> validateAssetByType(List<AssetDO> assetDOList,String type);
}
（3）具体的实现策略
这个就根据实际情况来实现，造火箭用造火箭的制造方法，造螺丝用造螺丝的方法。
@Component
public class RepairAssetValidate implements ValidateAssetService {
@Override
public Result<List<DetailsAppAsset>> validateAssetByType(List<AssetDO> assetDOList, String type) {
if( CollUtil.isEmpty(assetDOList) ){
return resultCreator.create(AssetErrorCode.ASSET_NOT_EXISTS, EntityConverter.convertList(assetDOList, DetailsAppAsset.class));
}
for(AssetDO assetDO : assetDOList){
if( assetDO.getQuoteOrderId() != null ){
return resultCreator.create(AssetValidErrorCode.ASSET_IN_OTHER_OPERATOR,"资产已被"+ QuoteOrderType.getQuoteOrderType(assetDO.getQuoteOrderType())+"引用" ,EntityConverter.convertList(assetDOList, DetailsAppAsset.class));
}
}
return resultCreator.create(ErrorCode.SUCCESS, EntityConverter.convertList(assetDOList, DetailsAppAsset.class));
}
@Override
public void afterPropertiesSet() throws Exception {
ValidAssetByTypeFactory.register(AssetValidateType.REPAIR.getValue(),this);
}
@Autowired
private ResultCreator resultCreator;
}
（4）做一个维护策略的枚举
其实这个可以不做，直接用字符串来获取策略map里面的具体策略也可以。
但是考虑到要管理起来，别最后起名没有规范，重名，或者不知道到底有多少相关的策略，实际上通过枚举管理起来挺好的，你想绕过这一步也是了可以的，毕竟不是强相关的一步。
public enum AssetValidateType implements StringOption {
ALLOCATE("allocate"),
BATCH_UPDATE_ASSET("batchUpdateAsset"),
UPDATE_BY_RESIDUAL("updateByResidual"),
CHANGE_USER_ASSET("changeUserAsset"),
BACK_ORDER("backOrder"),
BORROW_RETURN("borrowReturn"),
BORROW("borrow"),
COLLECT("collect"),
DISPOSE("dispose"),
RECYCLE("recycle"),
REPAIR("repair")
;
private String value;
AssetValidateType(String v){
setValue(v);
}
@Override
public void setValue(String value) {
this.value = value;
}
@Override
public String getValue() {
return this.value;
}
@Override
public boolean equals(String i) {
return this.getValue().equals(i);
}
}
好了这样就是一个完整的工厂模式+策略模式替代if else的方式
好处是代码看起来更简洁，不再是一大堆if else，而且方便扩展，不必扩展一个业务条件就写一个if的条件限制。
坏处是如果不是很复杂的业务这么写，会有设计过度的情况，对代码读写理解有一定要求，肯定没有入门那种if else方便看懂（其实shiro这些框架具有类似的设计，我当时看授权的这部分就很懵，不能直接debug一个一个往下跳，你要找最后实现的部分才能最后找对地方debug）
