说到代码中的 if-else会随着代码量的增加，在迭代的过程中变的越来越难以维护，
然后用工厂模式的思路可以把 if-else代码块给剥离开来，
不过有朋友提出了不足，
虽然表面上看没有 if-else了，但其实只是给挪到工厂里面去。
这不是换汤不换药嘛？
但其实想完全不用 if-else也是可能的，还是以上次那段代码为例子来说，
这是最终在调用端的代码
TargetExecutor executor = ExecutorFactory.getExecutor(target);
executor.process();
复制代码这是工厂类的代码
开始重构
我们关注的重点是 getExecutor()这个方法，这里一堆 if-else，
可以看到这里面的逻辑是根据 target 字符串的不同内容实例化不同的 executor对象给调用者使用，
也就是说，这里是一种多对多的模式，对于这种模式我们可以考虑用一个 HashMap来保存键值对，
private static HashMap<String, TargetExecutor> mMappings = new HashMap<>();
复制代码而判断 target内容的逻辑也不需要放在工厂类里了，可以重构 TargetExecutor的代码，给它增加一个抽象方法，
public abstract String matchUri();
复制代码这个方法的作用就是返回需要跟它匹配的字符串，
比如 ExecutorWithTag，那么它返回的是 "RANGE",
如果是 ExecutorWithStash，那么它返回的是 "#".
我们把新增的代码列出来，
准备工作好，还记得我们实例化了一个 HashMap吗，以String和Executor作为键值对的，
现在我们需要另外一个方法来把 executor放到 HashMap里，
完全摘除 if-else
在准备工作做到这里后，我们就需要来把工厂中的 if-else摘除了，
我们把之前的条件判断改成了从一个 map 中遍历查找匹配的模式，虽然从逻辑上来说，遍历查找跟 if-else差不多，
但代码会变更简洁，也不会再看到一长串的 if-else嵌套了，
下面是摘完之后的工厂类的代码，
这只是一种代码中的小技巧，可以在重构代码的时候让整个代码逻辑清晰很多，
但是也有弊端，
因为需要通过 pattern 去查找匹配，就会有可能出现 pattern 类似或者重叠的情况，一不小心就会导致bug...
对于这种情况上面的重构方法就没那么好了，
所以我习惯的话会把 if-else 剥离到工厂中就结束，但如果涉及到多个模块的人之间的合作的话，
才会再拆分一层，让大家自己把自己的 executor 在静态方法块中注册到 mMapping里，
这样各个模块之前的耦合就能降的很低，大家也就只需要关注自己的功能就行。
如果您对这篇文章有什么意见或者错误需要改进的地方,欢迎与我讨论。
