1700482595
设计模式之禅 35.2 混编小结
1700482596
1700482597
回顾一下我们在该案例中使用了几个模式。
1700482598
1700482599
❑策略模式
1700482600
1700482601
负责对扣款策略进行封装,保证两个策略可以自由切换,而且日后增加扣款策略也非常简单容易。
1700482602
1700482603
❑工厂方法模式
1700482604
1700482605
修正策略模式必须对外暴露具体策略的问题,由工厂方法模式直接产生一个具体策略对象,而其他模块则不需要依赖具体的策略。
1700482606
1700482607
❑门面模式
1700482608
1700482609
负责对复杂的扣款系统进行封装,封装的结果就是避免高层模块深入子系统内部,同时提供系统的高内聚、低耦合的特性。
1700482610
1700482611
我们主要使用了这三个模式,它们的好处是灵活、稳定,我们可以设想一下可能有哪些业务变化。
1700482612
1700482613
❑扣款策略变更
1700482614
1700482615
增加一个新扣款策略,三步就可以完成:实现IDeduction接口,增加StrategyMan配置项,扩展扣款策略的利用(也就是门面模式的getDeductionType方法,在实际项目中这里只需要增加数据库的配置项)。减少一个策略很简单,修改扣款策略的利用即可。变更一个扣款策略也很简单,扩展一个实现类口就可以了。
1700482616
1700482617
❑变更扣款策略的利用规则
1700482618
1700482619
我们的系统不想大修改,还记得我们提出的状态模式吗?这个就是为策略的利用服务的,变更它就能满足要求。想把IC卡也纳入策略利用的规则也不复杂。其实这个变更还真发生了,系统投产后,业务提出考虑退休人员的情况,退休人员的IC卡与普通在职员工一样,但是它的扣款不仅仅是根据交易编码,还要根据IC卡对象,系统的变更做法是增加一个扣款策略,同时扩展扣款利用策略,也就是数据库的配置项,在getDeductionType中新扩展了一个功能:根据IC卡号,确认是否是退休人员,是退休人员,则使用新的扣款策略,这是一个非常简单的扩展。
1700482620
1700482621
这就是一个mini版的金融交易系统,没啥复杂的,剩下的问题就是开始考虑系统的鲁棒性,这才是难点。
1700482622
1700482623
1700482624
1700482625
1700482627
设计模式之禅 第36章 观察者模式+中介者模式
1700482628
1700482630
36.1 事件触发器的开发
1700482631
1700482632
大家都应该做过桌面程序的开发吧,比如编写一个.exe文件,或者使用Java Swing编写一个应用程序,或者是用Delphi、C编写C/S结构的应用系统,即使这些都没有做过,那也总编写过B/S结构的页面吧?回忆一下开发过程,大家是不是经常使用文本框和按钮这两个控件?比如设计一个按钮,那总要编写鼠标点击处理,你是不是这样开发:在按钮的onClick函数中编写自己的逻辑代码,然后鼠标点击测试,该代码就会运行。大家有没有想过为什么我们点击了按钮就会触发我们自己编写的代码呢?浏览器怎么知道操作者按了按钮要触发该事件呢?鼠标点击动作、按钮、自己编写的代码之间是如何关联起来呢?
1700482633
1700482634
我们今天的任务就是来模拟类似触发过程。我们这样分析:有一个产品(不管是Frame还是Button或者是Radio),它有多个触发事件,它产生的时候触发一个创建事件,修改的时候触发修改事件,删除的时候触发删除事件,这就类似于我们的文本框,初始化(也就是创建)的时候要触发一个onLoad或onCreate事件,修改的时候触发onChange事件,双击(类似于删除)的时候又触发onDbClick事件,我们今天的目标就是来思考怎么实现这样一个架构。
1700482635
1700482636
设计都是先易后难,我们先从最简单的部分入手。首先需要一个产品,并且该产品要有创建、修改、销毁的动作,很明显这就是一个工厂方法模式。同时产品也可以通过克隆方式产生,这与我们在GUI设计中经常使用的复制粘贴操作相类似,要不界面上那么多的文本框,不使用复制粘贴,不累死人才怪呢,那这非常明显就是原型模式。好,分析到这里,我们先把这部分的类图建立起来,如图36-1所示。
1700482637
1700482638
很熟悉的类图,与工厂方法模式的通用类图非常相似,但不完全是。有什么差别呢?注意看产品类的私有属性canChanged和构造函数,它们有特殊的用途。在该类图中,我们使用了工厂方法模式创建产品,使用原型模式让对象可以被拷贝,仅仅这两个模式还不足以解决我们的问题,想想看,产品的产生是有一定的条件的,不是谁想产生就产生,否则怎么能够触发创建事件呢?因此需要限定产品的创建者,所以我们在类图中把产品和工厂的关系定位为组合关系,而不是简单的聚集或依赖关系。换句话说,产品只能由工厂类创建,而不能被其他对象通过new方式创建,因此我们在这里还用到一个单来源调用(Single Call)方法解决该问题。这是一个方法,不是一个设计模式,我马上给大家讲解它是如何工作的。我们先来看产品类的源代码,它比较简单,如代码清单36-1所示。
1700482639
1700482640
1700482641
1700482642
1700482643
图36-1 产品创建工厂
[
上一页 ]
[ :1.700482594e+09 ]
[
下一页 ]