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 事件分发者