1700482976
1700482977
//修改一个产品
1700482978
1700482979
public void editProduct（Product p,String name）{
1700482980
1700482981
//修改后的产品
1700482982
1700482983
p.setName（name）；
1700482984
1700482985
//产生修改事件
1700482986
1700482987
new ProductEvent（p,ProductEventType.EDIT_PRODUCT）；
1700482988
1700482989
}
1700482990
1700482991
//获得是否可以创建一个产品
1700482992
1700482993
public boolean isCreateProduct（）{
1700482994
1700482995
return isPermittedCreate；
1700482996
1700482997
}
1700482998
1700482999
//克隆一个产品
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