|
锁定老帖子 主题：用enum代替if.这个设计大家怎么看
精华帖 (0) :: 良好帖 (1) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-10-08
最后修改：2012-10-08
bubiaiyou 写道 抛出异常的爱 写道 bubiaiyou 写道 dohkoos 写道 纯粹就是没事找事，看到大家说if不好，就想着方地把if去掉，有这必要吗？有这个必要吗？
编程思想的重要一方面就是把过多的if去掉, 具有良好编程习惯的人不会频繁用到if的 哪个大仙说过的? 理论都懂,我没有说你完全不用if 不过你可以全部都用if, 适当的看情况而已,各有各的好坏, 减少了if就减少了复杂度同样功能 的 代码 就便宜了.? |
| 返回顶楼 | |
|
发表时间：2012-10-08
可读性差了不少，而且没看出有什么好处
|
| 返回顶楼 | |
|
发表时间：2012-10-08
看了这么多人发表反对意见又仔细看了一遍你的代码
你用for代替了以前的if，确实是一点好处都没有，还不如把if 改成 if else，照样每次请求判断了3次 你要是想简化，可以用map，也可以用工厂方法，将不同的方法提出来做个接口 getInstance（type）返回你方法的不同调用，这样才对 你现在这个确实是没有一点优化 |
| 返回顶楼 | |
|
发表时间：2012-10-08
congjl2002 写道 看了这么多人发表反对意见又仔细看了一遍你的代码
你用for代替了以前的if，确实是一点好处都没有，还不如把if 改成 if else，照样每次请求判断了3次 你要是想简化，可以用map，也可以用工厂方法，将不同的方法提出来做个接口 getInstance（type）返回你方法的不同调用，这样才对 你现在这个确实是没有一点优化 判断几次根本无所谓吧。不差那点性能。楼主这样改，好处是扩展时work方法不用修改了。符合ocp原则。 不过循环确实不优雅，比较好的作法是能够通过type生成实例，之前几位都讲了。 |
| 返回顶楼 | |
|
发表时间：2012-10-08
slertname 写道 判断几次根本无所谓吧。不差那点性能。楼主这样改，好处是扩展时work方法不用修改了。符合ocp原则。 不过循环确实不优雅，比较好的作法是能够通过type生成实例，之前几位都讲了。 work不用修改的代价是修改枚举类 |
| 返回顶楼 | |
|
发表时间：2012-10-08
lzxz1234 写道 slertname 写道 判断几次根本无所谓吧。不差那点性能。楼主这样改，好处是扩展时work方法不用修改了。符合ocp原则。 不过循环确实不优雅，比较好的作法是能够通过type生成实例，之前几位都讲了。 work不用修改的代价是修改枚举类 既然楼主提到重构，就要做些提高的的事情 现在改完的情况是代码可读性降低，同时并没有提升性能。判断几次是无所谓，但是如果这么想，每人请求一次多判断2次，10万人请求效果就明显了，每个部分都这样浪费机器的资源，整个系统也不会稳定 |
| 返回顶楼 | |
|
发表时间：2012-10-08
public class HandleSomething {
//Map 可以替换为你的Context
protected void work(int entryType, long userId, Map context) {
context.put("type", Flow.getInstance(entryType).handle(userId, context));
}
enum Flow {
VIP_ENTRY_FLOW(1) {
public int handle(long userId, Map context) {
return 0;
}
},
INDEX_ENTRY_FLOW(2) {
public int handle(long userId, Map context) {
return 0;
}
},
OTHERS_ENTRY_FLOW(3) {
public int handle(long userId, Map context) {
return 0;
}
};
private final int tag;
Flow(int tag) {
this.tag = tag;
}
public int getTag() {
return tag;
}
public static Flow getInstance(int tag) {
try{
//实现算法规则. 自己写. 无副作用.
return Flow.values()[tag-1];
}catch (Exception e) {
return Flow.OTHERS_ENTRY_FLOW;
}
}
public abstract int handle(long userId, Map context);
}
}
不知道这种写法 你中意不? |
| 返回顶楼 | |
|
发表时间：2012-10-08
lzxz1234 写道 slertname 写道 判断几次根本无所谓吧。不差那点性能。楼主这样改，好处是扩展时work方法不用修改了。符合ocp原则。 不过循环确实不优雅，比较好的作法是能够通过type生成实例，之前几位都讲了。 work不用修改的代价是修改枚举类 ocp又不是ccp， 修改枚举类难道不是open for extension吗？ |
| 返回顶楼 | |
|
发表时间：2012-10-08
xiaoyu211940 写道
public class HandleSomething {
//Map 可以替换为你的Context
protected void work(int entryType, long userId, Map context) {
context.put("type", Flow.getInstance(entryType).handle(userId, context));
}
enum Flow {
VIP_ENTRY_FLOW(1) {
public int handle(long userId, Map context) {
return 0;
}
},
INDEX_ENTRY_FLOW(2) {
public int handle(long userId, Map context) {
return 0;
}
},
OTHERS_ENTRY_FLOW(3) {
public int handle(long userId, Map context) {
return 0;
}
};
private final int tag;
Flow(int tag) {
this.tag = tag;
}
public int getTag() {
return tag;
}
public static Flow getInstance(int tag) {
try{
//实现算法规则. 自己写. 无副作用.
return Flow.values()[tag-1];
}catch (Exception e) {
return Flow.OTHERS_ENTRY_FLOW;
}
}
public abstract int handle(long userId, Map context);
}
}
不知道这种写法 你中意不? 好 |
| 返回顶楼 | |
|
发表时间：2012-10-08
抛出异常的爱 写道 1.这代码最大的问题在于contex的管理。。。。 太分散了。 但你引入的东西没有解决这个问题 我个人觉得，这个其实是代码的重点，if判断在这个类中，因为其简单，并且易于管理，存在的风险其实并不大。重点在于context的管理，在同一个类中的分散管理，将其再次分散到了其他的类中，在参数继续多样话以后，对其管理和可读性都存在越来越多的风险。 再次表现一下对“抛出异常的爱”的尊敬啊。。。。呵呵！！ |
| 返回顶楼 | |
