这是我重构之后的代码：各位大神看看呢，我一直在纠结设计模式..要疯==
10个回答
已采纳
在if 不满足条件时直接return掉，就不用写else了，这样可以减少if的深度
对于你的例子了，如下：
if (!tokenCheck.equals(token)) {
obj.setStatus();
obj.setMsg();
return obj;
}
if (!isContinue) {
obj.setStatus();
obj.setMsg();
return obj;
}
if (action == 20) {
// TODO
} else if (action == 30) {
// TODO
}
这样会让代码好看一点.
如果你纠结设计模式的话，可以把“调用系统通知”和"调用短信接口"抽象成策略，实现共同的接口；
每个策略提供一个accept方法用于判断是否接受传入的actionId，如果accept通过，就可调用该策略的execute方法。
List<Strategy> strategys = new ArrayList<>();
strategys.add(new SystemNoticeStrategy());
strategys.add(new MessageStrategy());
for (Strategy stragety : stragetys) {
if (strategy.accept(actionId)) {
strategy.execute();
break;
}
}
这个的缺点是要遍历list，其实性能开销并不会太大。
也可以把这些strategys放到map里，然后直接根据actionId从map中取出并执行。
这是一种实现思路，可能还会有更好的方式。
这点if else优化个毛线 企业应用那种炒鸡复杂的逻辑都是要跑工作流的 轮不到你业务开发操心
你优化完业务错了就好玩了
唯一一点看着很不爽的 就是你用了一堆println 老老实实找个log4j来用好嘛
复杂一点的应用可以往外甩异常，然后通用的功能，比如鉴权之类，放到拦截器里做，不要放业务里，这样能简洁一点，然而你如果业务就这么复杂优化什么呢
设计模式不是为了模式而模式的，等你哪天上了spring，mybatis这些，想不模式都难
如果再装一点B呢，提示文字要弄到配置里去，或者用i18n来做，每个引用的地方只放对应的id，要不以后改一句话找死你
推荐看 《重构:改善既有代码的设计》这本神书，可以解决代码设计上的很多问题，不仅仅是深层的if-else。
虽然有点答非所问的嫌疑，但冒死也要提交回答！
如果是我的话 我会写一个Map池，存进map里，直接从Map里取
嵌套的 if 可以通过细化成方法来优化
比如你这里
if (tokenCheck.equals(token)) {
doWork(...);
} else {
...
}
void doWork(...) {
if (isContinue) {
...
} else {
....
}
}
以此类推
你这里应该是说的判断actionId的if太多了吧。
如果每个if后面跟的业务逻辑很复杂你可以用多态来代替if
但是你这里似乎不是很复杂，也没什么大问题
if-eles 和 switch 在本质上没啥区别，如果条件特别多的话有两种方法细分
一种是先分大段，再分小段，比如
int n = id / 50;
switch (n) {
case 0:
do0_49(id);
break;
case 1:
do50_100(id);
break;
// ....
}另一种方法就是建表，把所有 id 对应的东西都放在表中，比如 HashTable。
如果是完全连续（或者少数不连接）的情况，就用数组或者 List 解决了。
你的这个问题中，键是 int，值是 String（保存消息文本） 就好，在其它更复杂的情况下，可以保存对象（比如 Listener 对象，或者 Command 对象之类的）
像这种情况，最常见的，也是效率较高的就是做查找表，或者Hash表
即：
建一个表：
Map ActionMap = new HashMap<Integer, String>(){
{
put(20, "ddd");
put(40, "line1\nline2");
}
};然后再直接索引输出：
System.out.println(ActoinMap.get(id));
1540
扫一扫
到【灌水乐园】发言
你没见过我们的if else，拿出来吓死你！！！
— 蒲柳隐逸 · 2016年01月20日