用enum代替if.这个设计大家怎么看

请教下您第三点的具体实现是怎么样的？感觉您说得有点道理的

我可没说一定要把if else去掉。并不是说把if去掉代码就多好了，但是有时候if/else过多会影响代码的可读性，也就是在特定的情况下过多的if能反应出一些问题.你说的策略模式不是这样用的，那请问你的意思是不应该使用枚举策略呢？还是在这个情景下不应该这样使用？以及原因？

如果work方法里有很多个if-else，有没有考虑过程序的可能执行路径是多少？成倍成倍啊！如果修改一处if代码块，所有的可能执行路径是否要测试？这些都是工作量。再如一些变量被work方法中的不同if代码块修改，那么work方法要做的回归测试量更大！

如果用多态，那么只测试修改的具体类就可以了。对work方法来说程序的执行路径只有一条。

  哥，你就那么看不起我啊！ 理都不理我啊！ switch 就能解决的问题难道是我理解错了，导致你不理我？

 

public class HandleSomething  {   
  
	private Manager manager;   
  
    private  Logger subLogger = LoggerFactory.getLogger(this.getClass());   
  

    protected void work( int entryType, long userId,Context context)  {   
  		switch(entryType){
				case 1: {
					context.put("type", vipFlow(userId,context)); 
					return;
				}
				case 2:{
					context.put("type", indexFlow(userId, context));   
				    return;   
				}
				case 3:{
					context.put("type", othersFlow(userId,context));   
				}
			}	
	
}

  private int vipFlow(long userId, Context context) {/*这里的逻辑用到manager和subLogger*/}   
  private int indexFlow(long userId, Context context) {/*这里的逻辑用到manager和subLogger*/}   
  private int othersFlow(long userId, Context context) {/*这里的逻辑用到manager和subLogger*/}   
}  

 

楼主应该从扩展的角度出发，如何在entryType类型新增等变更条件下做到尽量不修改原来流程代码，而使用类型注入或自动检测类型路由表的方式。
比如新增了一个类型处理类，类中带有路由信息与处理方式，通过标签或配置的方式配置，再另作一张路由表，主程序根据路由表获取对应的享元对象。

if else太多了当然不好，不过不是你这种解决办法。你这种办法只不过把if else的形式变了一下，翻译成汇编语言，还是一堆if else。你想想，如果有300个if else，那么你这个办法也要枚举300次，不对的。太多的分支，在java里面，就用map处理比较好，策略的实现类作为value注入到map里面，别说300个，300万个都可以的。

另外恕我技能拙劣，还真不知道有个叫枚举策略的写法，switch case倒是用过。策略模式是行为模式的一种，是以实现接口为基础的，不是你这样用的。

如果我们写程序的时候，第一反应是这个情况我应该用一种什么模式，那么证明你对设计模式还不熟悉，使用的时候就要慎重。

如果你的业务类型就那几种，在以后的扩展中还能扩展几种？？有没有必要这么设计？是否已经over design了?

建议你多看一下开源的源代码，特别是apache上的，至少比国内80%的人设计的好吧。举个具体的例子，开源博客软件Roller用Velocity作为默认模板引擎，但模板引擎不止一种啊，虽然改变模板引擎的概率不大，但人家设计还是为扩展预留空间。

是吗？OCP的要求是通过添加类实现添加功能，修改枚举类还是修改，修改A跟修改B不一样？

关于枚举策略的写法你可以参照effective java第二版的30条，另外策略模式通俗的理解可以理解为传递方法，接口实现只是实现该模式的一种具体方法，你可以比较下有指针的语言在实现策略模式的不同。另外也可以参照effective java第二版的21条。