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 事件分发者
1700483050
1700483051
public class EventDispatch implements Observer{
1700483052
1700483053
//单例模式
1700483054
1700483055
private final static EventDispatch dispatch=new EventDispatch（）；
1700483056
1700483057
//事件消费者
1700483058
1700483059
private Vector＜EventCustomer＞customer=new Vector＜EventCustomer＞（）；
1700483060
1700483061
//不允许生成新的实例
1700483062
1700483063
private EventDispatch（）{
1700483064
1700483065
}
1700483066
1700483067
//获得单例对象
1700483068
1700483069
public static EventDispatch getEventDispathc（）{
1700483070
1700483071
return dispatch；
1700483072
1700483073
}
1700483074
1700483075
//事件触发
[
上一页 ]
[ :1.700483026e+09 ]
[
下一页 ]