1700483000
1700483001
public Product clone(Product p){
1700483002
1700483003
//产生克隆事件
1700483004
1700483005
new ProductEvent(p,ProductEventType.CLONE_PRODUCT);
1700483006
1700483007
return p.clone();
1700483008
1700483009
}
1700483010
1700483011
}
1700483012
1700483013
在每个方法中增加了事件的产生机制,在createProduct方法中增加了创建产品事件,在editProduct方法中增加了修改产品事件,在delProduct方法中增加了遗弃产品事件,在clone方法中增加克隆产品事件,而且每个事件都是通过组合产生的,产品和事件的扩展性非常优秀。刚刚我们说完了产品和事件的关系处理,现在回到我们事件的观察者,它承担着非常重要的职责。我们知道它要处理事件,但是现在还没有想好怎么实现它处理事件的update方法,暂时保持为空。
1700483014
1700483015
我们继续分析,这么多的事件(现在只有1个产品类,如果产品类很多呢?比如30多个)不可能每个产品事件都写一个处理者吧,对于产品事件来说,它最希望的结果就是我通知了事件处理者(也就是观察者模式的观察者),其他具体怎么处理由观察者来解决,那现在问题是观察者怎么来处理这么多的事件呢?事件的处理者必然有N多个,如何才能通知相应的处理者来处理事件呢?一个事件也可能通知多个处理者来处理,并且一个处理者处理完毕还可能通知其他的处理者,这不可能让每个处理者独自完成这样“不可能完成的任务”,我们把问题的示意图画出来,如图36-4所示。
1700483016
1700483017
1700483018
1700483019
1700483020
图36-4 事件处理示意图
1700483021
1700483022
看到该示意图,你立刻就会想到中介者模式。是的,需要中介者模式上场了,我们把EventDispatch类(嘿嘿,为什么要定义成Dispatch呢?就是分发的意思)作为事件分发的中介者,事件的处理者都是具体的同事类,它们有着相似的行为,都是处理产品事件,但是又有不相同的逻辑,每个同事类对事件都有不同的处理行为。我们来看类图,如图36-5所示。
1700483023
1700483024
1700483025
1700483026
1700483027
图36-5 采用中介者模式对事件进行分发
1700483028
1700483029
在类图中,EventDispatch类有3个职责。
1700483030
1700483031
❑事件的观察者
1700483032
1700483033
作为观察者模式中的观察者角色,接收被观察期望完成的任务,在我们的框架中就是接收ProductEvent事件。
1700483034
1700483035
❑事件分发者
1700483036
1700483037
作为中介者模式的中介者角色,它担当着非常重要的任务——分发事件,并同时协调各个同事类(也就是事件的处理者)处理事件。
1700483038
1700483039
❑事件处理者的管理员角色
1700483040
1700483041
不是每一个事件的处理者都可以接收事件并进行处理,是需要获得分发者许可后才可以,也就是说只有事件分发者允许它处理,它才能处理。
1700483042
1700483043
事件分发者担当了这么多的职责,那是不是与单一职责原则相违背了?确实如此,我们在整个系统的设计中确实需要这样一个角色担任这么多的功能,如果强制细分也可以完成,但是会加大代码量,同时导致系统的结构复杂,读者可以考虑拆分这3个职责,然后再组合相关的功能,看看代码量是如何翻倍的。
1700483044
1700483045
注意 设计原则只是一个理论,而不是一个带有刻度的标尺,因此在系统设计中不应该把它视为不可逾越的屏障,而是应该把它看成是一个方向标,尽量遵守,而不是必须恪守。
1700483046
1700483047
既然事件分发者这么重要,我们就仔细研读一下它的代码,如代码清单36-7所示。
1700483048
1700483049
代码清单36-7 事件分发者
[
上一页 ]
[ :1.700483e+09 ]
[
下一页 ]