Interpreter模式的意图是可以按照自己定义的组合规则集合来组合可执行对象
下面就讲一个我们日常最经常碰到的实例:
如一个公司有如下层次总裁(President),老板(Boss),项目经理(Manager),员工(Employee)
一天,总裁接到一个邀请开发一套医疗管理系统,于是它就把老板叫来跟他简单说一下大概,然后就把相关事情交给老板了。
老板接到任务之后,看了看,就挑了一个精明能干的开发四部项目经理(***)去安排。四部经理拿到任务之后,立即对任务进行安排.
设计图示如下:
上面的故事中都体现着一个意思就是每个层次都是根据上级的指令进行安排任务,所以我们就定义一个接口为Command
用于接收并传递指令给相应的下一级
总裁(president)是最上一级的人物,他收到任务之后只要把老板叫过来,并把东西丢给他,然后就是拍拍屁股出去溜达去了
老板收到总裁的命令之后,他必须选择一个能够用途这个任务的经理,所以他要做的就是如何去找一个能干的人并把任务交给它,然后就是给他施压.
这聪明的老板选择项目经理之后,也就没他的事了,平时也就看看项目进展如何,然后陪总裁出去FB了。接下来的任务就是项目经理怎么去应对这些事情了。PM收到任务之后就开始对任务进行安排,对总体进行计划。他首先把客户找来,安排DBA进行数据分析,找文档撰写者开发文档,然后给领导评审。接着就是开发....然后继续交互,这样的敏捷式开发直到项目OVER啦。
接下来就是我们这辛苦的民工们了,能做的就是响应Manager的命令进行开发
测试方法如下:
输出结果:
领导叫我们:开发医疗系统,大家开始干活! role:dba
领导叫我们:开发医疗系统,大家开始干活! role:docs
领导叫我们:开发医疗系统,大家开始干活! role:tests
领导叫我们:开发医疗系统,大家开始干活! role:tests
领导叫我们:开发医疗系统,大家开始干活! role:tests
领导叫我们:开发医疗系统,大家开始干活! role:tests
领导叫我们:开发医疗系统,大家开始干活! role:tests
领导叫我们:开发医疗系统,大家开始干活! role:tests
领导叫我们:开发医疗系统,大家开始干活! role:tests
领导叫我们:开发医疗系统,大家开始干活! role:tests
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
领导叫我们:开发医疗系统,大家开始干活! role:engineers
解释器模式意在强调解释器的工作方式