策略型业务逻辑处理选择

目前常见的分层结构是包括展现层、业务逻辑层、持久层的。

 

 

 

那么在业务逻辑层中，是会有非常多的复杂的业务逻辑判断的，例如：

if (A.getA() == Type.A) {
	//do something for Type.High
} else if (A.getA() ==Type.Higher) {
	if (A.getB() == null) {
		//do something else for Type.Higher with B is null
	} else {
		for (B b: A.getB()) {
			if (b.getB() < 0) {
				//do something other
			}
		}
	}
}

这些if-else判断是有非常多的弊端的

1. 对于新的需求，代码很难做出变更
2. 随着更多条件的加入，代码性能显著下降
3. 如果要改变应用的行为，还需要重新编译和重新发布应用程序
4. 对于开发人员，难以修改代码；对于领域专家，很难验证业务逻辑，更别说修改业务逻辑

遇到这种情况来说，一种选择是用一些设计模式去处理，最常见的就是策略模式，这种设计模式主要的核心就是将策略封装成为类，并依赖于主题上下文中，，下面是策略模式实例的UML图：

 

这个模式在一定程度上是可以解除if和else带来的判断策略复杂性问题，而且能够做到开闭原则，但是依旧没有完全解决上面的那些弊端。并且这种设计模式还带来了一些缺点，例如策略类的增加等。

 

其实还有一种选择就是找一个规则引擎工具，例如开源的Drools和商业的iLog等。

规则引擎是一种嵌套在应用程序中的组件，实现了将业务规则从应用程序代码中分离出来。规则引擎使用特定的语法编写业务规则，规则引擎可以接受数据输入、解释业务规则、并根据业务规则做出相应的决策。下面是加入规则引擎和没有加入规则引擎的对比图：

 

 

 

利用规则引擎可以解决很多if-else带来的弊端，这里包括：易于理解；提高了可维护性；可处理更复杂的业务逻辑；灵活；合理的性能；；可重用等。

但是这种工具也是会有一定的局限性和缺点，例如：规则引擎只是将事情变得简单些，它不是万能钥匙；开发人员需要站在业务人员角度制定规则；如果不懂得规则引擎的运行模式，调试规则会有些困难；规则引擎消耗内存等。

 

在遇到业务逻辑层负责策略的时候，需要根据不同的情况来进行选择，其实目的都是一致的，就是面向对象的好处--易维护、易扩展、高质量等。