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

我认为这个想法不错。

我来献丑一下，不要if的，但要一个for循环，和读配置文件，（稍微有点复杂了）

public class HandleSomething {

	private static Log log = LogFactory.getLog(HandleSomething.class);
         //对象容器
	private static Map<String,Flow> flows = new HashSet<String,Flow>();

	static {//初始化对象容器
		String userFlows = getProperty("handle.userFlows");
		Flow flow = null;
		String[] uFactories = userFlows.split(",");
		for (int i = 0; i < uFactories.length; i++) {
			try {
				Class factoryClass = Class.forName(uFactories[i]);
				flow = (Flow) factoryClass.newInstance();
				flows.put(String.valueOf(i + 1), flow);
			} catch (ClassCastException cce) {
			} catch (Exception e) {
			}
		}

	}

	/**
	 * 
	 * @param entryType
	 * @param userId
	 * @param context
	 */
	protected void work(int entryType, long userId, Context context) {
		Flow flow = flows.get(String.valueOf(entryType));
		context.put("type", flow.handle(userId, context));
	}

	private static String getProperty(String string) {
		// 读取属性文件
		//handle.userFlows=com.xxx.VipFlow,com.xxx.IndexFlow,com.xxx.OthersFlow,
		return null;
	}

     //定义一个接口
	interface Flow {
		int handle(long userId, Context context);
	}

	class VipFlow implements Flow {

		public int handle(long userId, Context context) {
			// TODO Auto-generated method stub
			return 0;
		}

	}

	class IndexFlow implements Flow {

		public int handle(long userId, Context context) {
			// TODO Auto-generated method stub
			return 0;
		}

	}

	class OthersFlow implements Flow {

		public int handle(long userId, Context context) {
			// TODO Auto-generated method stub
			return 0;
		}

	}

}

楼主，这个Context作用域是全局的吧，如果这样就会有并发问题。
protected void work( int entryType, long userId,Context context)

我们都知道。程序离不开顺序，选择，循环，所以不管怎么样，这归根究底还是选择。
只是书写的时候没看到if而已。
甚至我们可任说是把if包装了。
所以概念上都一样都是选择分支。
但是如果说代码简洁，其实你是写java代码，目的是把产品交给客户，与此同时还有重要的问题，以后可能别人来维护。
因此重点是书写代码的速度，和别人读代码的速度。
综上所述，既然本质都是选择，那么不如把选择给抽象出来搞出一个路由。

从编程角度if没什么不好，但是从业务角度程序员看到一堆if else如果注释不清楚就会乱，所以把if去掉让代码从业务层面更整洁，便于后面维护的人浏览

代码似乎变得更好了，但是个人认为还是有问题。

1.易读性，可维护性。枚举变得不易读。
2.开闭原则。
3.职责单一，枚举的职责已经不再简单。
4.耦合性，枚举和manage存在相互的依赖，新增业务需要修改两个地方。

模式可以再提炼，可以看看spring mvc的处理，@Controller，@RequestMapping

典型的 工厂模式 + 单例模式

if else是程序中避免不了的写法，为什么非要去掉呢？而且从理论上讲也去不掉啊。

这个修改我看没什么实际意义，而且策略模式也不是这样用的。真要把if else去掉，还是map来的实惠，和spring搭配，能够直接往map里面注入行为实现类，比这个写法好看得多。

如果是key值判断映射到value处理，我觉得不如用责任连模式，注册一个责任连，然后对应的处理

无聊的重构，简单的代码变复杂了，可读性也下降了。我觉得程序只有一个原则要遵守,DRY(Don't repeat yourself)