王大虎

王大虎:26.3 状态模式的应用

 

王大虎

26.3.2 状态模式的缺点

 

状态模式既然有优点,那当然有缺点了。但只有一个缺点,子类会太多,也就是类X。如果一个事物有很多个状态也不稀奇,如果完全使用状态模式就会有太多的子类,不好管理,这个需要大家在项目中自己衡量。其实有很多方式可以解决这个状态问题,如在数据库中建立一个状态表,然后根据状态执行相应的操作,这个也不复杂,看大家的习惯和嗜好了。

 

 

26.3.3 状态模式的使用场景

 

·行为随状态改变而改变的场景

这也是状态模式的根本出发点,例如权限设计,人员的状态不同即使执行相同的行为结果也会不同,在这种情况下需要考虑使用状态模式。

·条件、分支判断语句的替代者

在程序中大量使用switch语句或者if判断语句会导致程序结构不清晰,逻辑混乱,使用状态模式可以很好地避免这一问题,它通过扩展子类实现了条件的判断处理。

 

 

26.3.4 状态模式的注意事项

王大虎

状态模式适用于当某个对象在它的状态发生改变时,它的行为也随着发生比较大的变化,也就是说在行为受状态约束的情况下可以使用状态模式,而且使用时对象的状态最好不要超过5个。

 

 

26.4 最佳实践

 

上面的例子可能比较复杂,请各位看官耐心看,看完肯定有所收获。我翻遍了所有能找得到的资料(关于这个电梯的例子也是由《Design Pattern for Dummies》这本书激发出来的),基本上没有一本把这个状态模式讲透彻的(当然,还是有几本讲得不错),我不敢说我就讲得透彻,大家都只讲了一个状态到另一个状态的过渡。状态间的过渡是固定的,举个简单的例子,如图26-6所示。

 

图26-6 简单状态切换示意图

这个状态图是很多书上都有的,状态A只能切换到状态B,状态B再切换到状态C。举例最多的就是TCP监听的例子。TCP有3个状态:等待状态、连接状态、断开状态,然后这3个状态按照顺序循环切换。按照这个状态变更来讲解状态模式,我认为是不太合适的,为什么呢?你在项目中很少看到一个状态只能过渡到另一个状态情形,项目中遇到的大多数情况都是一个状态可以转换为几种状态,如图26-7所示。

 

图26-7 复杂状态切换示意图

状态B既可以切换到状态C,又可以切换到状态D,而状态D也可以切换到状态A或状态B,这在项目分析过程中有一个状态图可以完整地展示这种蜘蛛网结构,例如,一些收费网站的用户就有很多状态,如普通用户、普通会员、VIP会员、白金级用户等,这个状态的变更你不允许跳跃?!这不可能,所以我在例子中就举了一个比较复杂的应用,基本上可以实现状态间X切换,这才是最经常用到的状态模式。

再提一个问题,状态间的X切换,那会有很多种呀,你要挨个去牢记一遍吗?比如上面那个电梯的例子,我要一个正常的电梯运行逻辑,规则是开门->关门->运行->停止;还要一个紧急状态(如火灾)下的运行逻辑,关门->停止,紧急状态时,电梯当然不能用了;再要一个维修状态下的运行逻辑,这个状态任何情况都可以,开着门电梯运行?可以!门来回开关?可以!永久停止不动?可以!那这怎么实现呢?需要我们把已经有的几种状态按照一定的顺序再重新组装一下,那这个是什么模式?什么模式?大声点!建造者模式!对,建造模式+状态模式会起到非常好的封装作用。

更进一步,应该有部分读者做过工作流开发,如果不是土制框架,那么就应该有个状态机管理(即使是土制框架也应该有),如一个Activity(节点)有初始化状态(Initialized State)、挂起状态(Suspended State)、完成状态(Completed State)等,流程实例也有这么多状态,那这些状态怎么管理呢?通过状态机(State Machine)来管理,那状态机是个什么东西呢?就是我们上面提到的Context类的升级XBOSS!

王大虎
王大虎

 

第27章 解释器模式

王大虎

27.1 四则运算你会吗

 

在银行、证券类项目中,经常会有一些模型运算,通过对现有数据的统计、分析而预测不可知或未来可能发生的商业行为。模型运算大部分是针对海量数据的,例如建立一个模型公式,分析一个城市的消费倾向,进而影响银行的营销和业务扩张方向。一般的模型运算都有一个或多个运算公式,通常是加、减、乘、除四则运算,偶尔也有指数、开方等复杂运算。具体到一个金融业务中,模型公式是非常复杂的,虽然只有加、减、乘、除四则运算,但是公式有可能有十多个参数,而且上百个业务品各有不同的取参路径,同时相关表的数据量都在百万级。呵呵,复杂了吧,不复杂那就不叫金融业务,我们来讲讲运算的核心——模型公式及其如何实现。

业务需求:输入一个模型公式(加、减运算),然后输入模型中的参数,运算出结果。

设计要求:

·公式可以运行时编辑,并且符合正常算术书写方式,例如a+b-c。

·高扩展性,未来增加指数、开方、极限、求导等运算符号时较少改动。

·效率可以不用考虑,晚间批量运算。

需求不复杂,若仅仅对数字采用四则运算,每个程序员都可以写出来。但是增加了增加模型公式就复杂了。先解释一下为什么需要公式,而不采用直接计算的方法,例如有如下3个公式:

·业务种类1的公式:a+b+c-d。

·业务种类2的公式:a+b+e-d。

·业务种类3的公式:a-f。

其中,a、b、c、d、e、f参数的值都可以取得,如果使用直接计算数值的方法需要为每个品种写一个算法,目前仅仅是3个业务种类,那上百个品种呢?歇菜了吧!建立公式,然后通过公式运算才是X。

我们以实现加、减算法(由于篇幅所限,乘、除法的运算读者可以自行扩展)的公式为例,讲解如何解析一个固定语法逻辑。由于使用语法解析的场景比较少,而且一些商业公司(如SAS、SPSS等统计分析软件)都支持类似的规则运算,亲自编写语法解析的工作已经非常少,以下例程采用逐步分析方法,带领大家了解这一实现过程。

想想公式中有什么?仅有两类元素:运算元素和运算符号,运算元素就是指a、b、c等符号,需要具体赋值的对象,也叫做终结符号,为什么叫终结符号呢?因为这些元素除了需要赋值外,不需要做任何处理,所有运算元素都对应一个具体的业务参数,这是语法中最小的单元逻辑,不可再拆分;运算符号就是加减符号,需要我们编写算法进行处理,每个运算符号都要对应处理单元,否则公式无法运行,运算符号也叫做非终结符号。两类元素的共同点是都要被解析,不同点是所有的运算元素具有相同的功能,可以用一个类表示,而运算符号则是需要分别进行解释,加法需要加法解析器,减法需要减法解析器。分析到这里,我们就可以先画一个简单的类图,如图27-1所示。

王大虎

图27-1 初步分析加减法类图

这是一个很简单的类图,VarExpression用来解析运算元素,各个公式能运算元素的数量是不同的,但每个运算元素都对应一个VarExpression对象。SybmolExpression负责解析符号,由两个子类AddExpression(负责加法运算)和SubExpression(负责减法运算)来实现。解析的工作完成了,我们还需要把安排运行的先后顺序(加减法不用考虑,但是乘除法呢?注意扩展性),并且还要返回结果,因此我们需要增加一个封装类来进行封装处理,由于我们只做运算,暂时还不与业务有关联,定义为Calculator类。分析到这里,思路就比较清晰了,优化后加减法类图如图27-2所示。

Calculator的作用是封装,根据迪米特法则,Client只与直接的朋友Calculator交流,与其他类没关系。整个类图的结构比较清晰,下面填充类图中的方法,完整类图如图27-3所示。

类图已经完成,下面来看代码实现。Expression抽象类如代码清单27-1所示。

代码清单27-1 抽象表达式类

 

* * *

 

public abstract class Expression { //解析公式和数值,其中var中的key值是是公式中的参数,value值是具体的数字 public abstract int interpreter(HashMap<String,Integer> var); }

 

* * *

 

 

图27-2 优化后加减法类图

 

图27-3 完整加减法类图

抽象类非常简单,仅一个方法interpreter负责对传递进来的参数和值进行解析和匹配,其中输入参数为HashMap类型,key值为模型中的参数,如a、b、c等,value为运算时取得的具体数字。

变量解析器如代码清单27-2所示。

代码清单27-2 变量解析器

 

* * *

 

public class VarExpression extends Expression { private String key; public VarExpression(String _key){ this.key = _key; } //从map中取之 public int interpreter(HashMap<String, Integer> var) { return var.get(this.key); } }

 

王大虎

 

抽象运算符号解析器如代码清单27-3所示。

代码清单27-3 抽象运算符号解析器

 

* * *

 

public abstract class SymbolExpression extends Expression { protected Expression left; protected Expression right; //所有的解析公式都应只关心自己左右两个表达式的结果 public SymbolExpression(Expression _left,Expression _right){ this.left = _left; this.right = _right; } }

 

* * *

 

这个解析过程还是比较有意思的,每个运算符号都只和自己左右两个数字有关系,但左右两个数字有可能也是一个解析的结果,无论何种类型,都是Expression的实现类,于是在对运算符解析的子类中增加了一个构造函数,传递左右两个表达式。具体的加、减法解析器如代码清单27-4、代码清单27-5所示。

代码清单27-4 加法解析器

 

* * *

 

public class AddExpression extends SymbolExpression { public AddExpression(Expression _left,Expression _right){ super(_left,_right); } //把左右两个表达式运算的结果加起来 public int interpreter(HashMap<String, Integer> var) { return super.left.interpreter(var) + super.right.interpreter(var); } }

 

* * *

 

代码清单27-5 减法解析器

 

王大虎

 

public class SubExpression extends SymbolExpression { public SubExpression(Expression _left,Expression _right){ super(_left,_right); } //左右两个表达式相减 public int interpreter(HashMap<String, Integer> var) { return super.left.interpreter(var) – super.right.interpreter(var); } }

 

* * *

 

解析器的开发工作已经完成了,但是需求还没有完全实现。我们还需要对解析器进行封装,封装类Calculator如代码清单27-6所示。

代码清单27-6 解析器封装类

发表评论

电子邮件地址不会被公开。 必填项已用*标注