来吧,用设计模式来干掉 if-else( 五 )

接下来改造ReceiptHandlerContainer
public class ReceiptHandlerContainer {    private ReceiptHandlerContainer(){}    public static List<IReceiptHandler> getReceiptHandlerList(){        List<IReceiptHandler> receiptHandlerList = new ArrayList<>();        //获取IReceiptHandler接口的实现类        Set<Class<?>> classList = ReflectionUtil.getClassSetBySuper(IReceiptHandler.class);        if (classList != null && classList.size() > 0) {            for (Class<?> clazz : classList) {                try {                    receiptHandlerList.add((IReceiptHandler)clazz.newInstance());                } catch ( Exception e) {                    e.printStackTrace();                }            }        }        return receiptHandlerList;    }}至此 , 该方案完美符合了开闭原则 , 如果新增一个回执类型 , 只需要添加一个新的回执处理器即可 , 无需做其它改动 。如新加了MT6666的回执 , 代码如下
public class Mt6666ReceiptHandler implements IReceiptHandler {    @Override    public void handleReceipt(Receipt receipt, IReceiptHandleChain handleChain) {        if (StringUtils.equals("MT6666",receipt.getType())) {            System.out.println("解析报文MT6666:" + receipt.getMessage());        }        //处理不了该回执就往下传递        else {            handleChain.handleReceipt(receipt);        }    }}策略模式+注解此方案其实和上述没有太大异同 , 为了能符合开闭原则 , 通过自定义注解的方式 , 标记处理者类 , 然后反射获取到该类集合 , 放到Map容器中 , 这里不再赘述
小结if-else或switch case 这种分支判断的方式对于分支逻辑不多的简单业务 , 还是直观高效的 。对于业务复杂 , 分支逻辑多 , 采用适当的模式技巧 , 会让代码更加清晰 , 容易维护 , 但同时类或方法数量也是倍增的 。我们需要对业务做好充分分析 , 避免一上来就设计模式 , 避免过度设计!
作者:DiDi516
cnblogs.com/DiDi516/p/11787257.html

【来吧,用设计模式来干掉 if-else】


推荐阅读