第36章　观察者模式+中介者模式 · 设计模式之禅（第2版）

第36章　观察者模式+中介者模式 36.1 事件触发器的开发大家都应该做过桌面程序的开发吧，比如编写一个EXE文件，或者使用Java Swing编写一个应用程序，或者是用Delphi、C编写C/S结构的应用系统，即使这些都没有做过，那也总编写过B/S结构的页面吧？回忆一下开发过程，大家是不是经常使用文本框和按钮这两个控件？比如设计一个按钮，那总要编写鼠标点击处理，你是不是这样开发：在按钮的onClick函数中编写自己的逻辑代码，然后鼠标点击测试，该代码就会运行。大家有没有想过为什么我们点击了按钮就会触发我们自己编写的代码呢？浏览器怎么知道操作者按了按钮要触发该事件呢？鼠标点击动作、按钮、自己编写的代码之间是如何关联起来呢？我们今天的任务就是来模拟类似触发过程。我们这样分析：有一个产品（不管是Frame还是Button或者是Radio），它有多个触发事件，它产生的时候触发一个创建事件，修改的时候触发修改事件，删除的时候触发删除事件，这就类似于我们的文本框，初始化（也就是创建）的时候要触发一个onLoad或onCreate事件，修改的时候触发onChange事件，双击(类似于删除)的时候又触发onDbClick事件，我们今天的目标就是来思考怎么实现这样一个架构。设计都是先易后难，我们先从最简单的部分入手。首先需要一个产品，并且该产品要有创建、修改、销毁的动作，很明显这就是一个工厂方法模式。同时产品也可以通过克隆方式产生，这与我们在GUI设计中经常使用的复制粘贴操作相类似，要不界面上那么多的文本框，不使用复制粘贴，不累死人才怪呢，那这非常明显就是原型模式。好，分析到这里，我们先把这部分的类图建立起来，如图36-1所示。很熟悉的类图，与工厂方法模式的通用类图非常相似，但不完全是。有什么差别呢？注意看产品类的私有属性canChanged和构造函数，它们有特殊的用途。在该类图中，我们使用了工厂方法模式创建产品，使用原型模式让对象可以被拷贝，仅仅这两个模式还不足以解决我们的问题，想想看，产品的产生是有一定的条件的，不是谁想产生就产生，否则怎么能够触发创建事件呢？因此需要限定产品的创建者，所以我们在类图中把产品和工厂的关系定位为组合关系，而不是简单的聚集或依赖关系。换句话说，产品只能由工厂类创建，而不能被其他对象通过new方式创建，因此我们在这里还用到一个单来源调用（Single Call）方法解决该问题。这是一个方法，不是一个设计模式，我马上给大家讲解它是如何工作的。 ![](https://box.kancloud.cn/2016-08-14_57b0037096538.jpg) 图36-1 产品创建工厂我们先来看产品类的源代码，它比较简单，如代码清单36-1所示。代码清单36-1 产品类 public class Product implements Cloneable{ //产品名称 private String name; //是否可以属性变更 private boolean canChanged = false; //产生一个新的产品 public Product(ProductManager manager,String _name){ //允许建立产品 if(manager.isCreateProduct()){ canChanged =true; this.name = _name; } } public String getName() { return name; } public void setName(String name) { if(canChanged){ this.name = name; } } //覆写clone方法 @Override public Product clone(){ Product p =null; try { p =(Product)super.clone(); } catch (CloneNotSupportedException e) { e.printStackTrace(); } return p; } } 在产品类中，我们只定义产品的一个属性：产品名称（name），并实现了getter/setter方法，然后我们实现了它的clone方法，确保对象是可以被拷贝的。还有一个特殊的地方是我们的构造函数，它怎么会要求传递进来一个工厂对象ProductManager呢？保留你的好奇心，马上为你揭晓答案。我们继续看代码，工厂类如代码清单36-2所示。代码清单36-2 工厂类 public class ProductManager { //是否可以创建一个产品 private boolean isPermittedCreate = false; //建立一个产品 public Product createProduct(String name){ //首先修改权限，允许创建 isPermittedCreate = true; Product p = new Product(this,name); return p; } //废弃一个产品 public void abandonProduct(Product p){ //销毁一个产品，例如删除数据库记录 p = null; } //修改一个产品 public void editProduct(Product p,String name){ //修改后的产品 p.setName(name); } //获得是否可以创建一个产品 public boolean isCreateProduct(){ return isPermittedCreate; } //克隆一个产品 public Product clone(Product p){ //产生克隆事件 return p.clone(); } } 仔细看看工厂类，产品的创建、修改、遗弃、克隆方法都很简单，但有一个方法可不简单——isCreateProduct方法，它的作用是告诉产品类“我是能创建产品的”，注意看我们的程序，在工厂类ProductManager中定义了一个私有变量isCreateProduct，该变量只有在工厂类的createProduct函数中才能设置为true，在创建产品的时候，产品类Product的构造函数要求传递工厂对象，然后判断是否能够创建产品，即使你想使用类似这样的方法： Product p = new Product(new ProductManager(),"abc"); 也是不可能创建出产品的，它在产品类中限制必须是当前有效工厂才能生产该产品，而且也只有有效的工厂才能修改产品，看看产品类的canChanged属性，只有它为true时，产品才可以修改，那怎么才能为true呢？在构造函数中判断是否可以为true。这就类似工厂要创建产品了，产品就问“你有权利创建我吗？”于是工厂类出示了两个证明材料证明自己可以创建产品：一是“我是你的工厂类”，二是“我的isCreateProduct返回true，我有权创建”，于是产品就被创建出来了。这种一个对象只能由固定的对象初始化的方法就叫做单来源调用（Single Call）——很简单，但非常有用的方法。注意　采用单来源调用的两个对象一般是组合关系，两者有相同的生命期，它通常适用于有单例模式和工厂方法模式的场景中。我们继续往下分析，一个产品新建要触发事件，那事件是什么？当然也是一个对象了，需要把它设计出来，仅仅有事件还不行，还要考虑有人去处理这个事件，产生了一个事件不可能没有对象去处理吧？如果是这样那事件还有什么意义呢？既然要去处理，那就需要一个通知渠道了，于是观察者模式准备好了。好，我们把这段分析的类图也画出来，如图36-2所示。 ![](https://box.kancloud.cn/2016-08-14_57b00370aff64.jpg) 图36-2 观察者模式处理事件在该类图中，观察者为EventDispatch类，它使用了单例模式，避免对象膨胀，但同时也带来了性能及线程安全隐患，这点需要大家在实际应用中注意（想想Spring中的Bean注入，默认也是单例，在通常的应用中一般不需要修改，除非是较大并发的应用）。我们来看代码，先来看事件类型定义，它是一个枚举类型，如代码清单36-3所示。代码清单36-3 事件类型定义 public enum ProductEventType { //新建一个产品 NEW_PRODUCT(1), //删除一个产品 DEL_PRODUCT(2), //修改一个产品 EDIT_PRODUCT(3), //克隆一个产品 CLONE_PRODUCT(4); private int value=0; private ProductEventType(int _value){ this.value = _value; } public int getValue(){ return this.value; } } 这里定义了4个事件类型，分别是新建、修改、删除以及克隆，比较简单。我们再来看产品的事件，如代码清单36-4所示。代码清单36-4 产品事件 public class ProductEvent extends Observable{ //事件起源 private Product source; //事件的类型 private ProductEventType type; //传入事件的源头，默认为新建类型 public ProductEvent(Product p) { this(p,ProductEventType.NEW_PRODUCT); } //事件源头以及事件类型 public ProductEvent(Product p,ProductEventType _type){ this.source = p; this.type = _type; //事件触发 notifyEventDispatch(); } //获得事件的始作俑者 public Product getSource(){ return source; } //获得事件的类型 public ProductEventType getEventType(){ return this.type; } //通知事件处理中心 private void notifyEventDispatch(){ super.addObserver(EventDispatch.getEventDispatch()); super.setChanged(); super.notifyObservers(source); } } 我们在产品事件类中增加了一个私有方法notfiyEventDispatch，该方法的作用是明确事件的观察者，并同时在初始化时通知观察者，它在有参构造中被调用。我们再来看事件的观察者，如代码清单36-5所示。代码清单36-5 事件的观察者 public class EventDispatch implements Observer{ //单例模式 private final static EventDispatch dispatch = new EventDispatch(); //不允许生成新的实例 private EventDispatch(){ } //获得单例对象 public static EventDispatch getEventDispatch(){ return dispatch; } //事件触发 public void update(Observable o, Object arg) { } } 产品和事件都定义出来了，那我们想想怎么把这两者关联起来，产品和事件是两个独立的对象，两者都可以独立地扩展，用什么来适应它们的扩展呢？桥梁模式！两个不相关的类可以通过桥梁模式组合出稳定、健壮的结构，我们画出类图，如图36-3所示。 ![](https://box.kancloud.cn/2016-08-14_57b00370cb736.jpg) 图36-3 桥梁模式实现产品和事件的组合看着不像桥梁模式？看看桥梁模式的通用类图，然后把抽象化角色和实现化角色去掉看看，是不是就是一样了？各位可能要说了，把抽象化角色和实现化角色去掉，那桥梁模式在抽象层次耦合的优点还怎么体现呢？因为我们采用的是单个产品对象，没有必要进行抽象化处理，读者若要按照该框架做扩展开发，该部分是肯定需要抽象出接口或抽象类的，好在也非常简单，只要抽取一下就可以了。这样考虑后，我们的ProductManager类就增加一个功能：组合产品类和事件类，产生有意义的产品事件，如代码清单36-6所示。代码清单36-6 修正后的产品工厂类 public class ProductManager { //是否可以创建一个产品 private boolean isPermittedCreate = false; //建立一个产品 public Product createProduct(String name){ //首先修改权限，允许创建 isPermittedCreate = true; Product p = new Product(this,name); //产生一个创建事件 new ProductEvent(p,ProductEventType.NEW_PRODUCT); return p; } //废弃一个产品 public void abandonProduct(Product p){ //销毁一个产品，例如删除数据库记录 //产生删除事件 new ProductEvent(p,ProductEventType.DEL_PRODUCT); p = null; } //修改一个产品 public void editProduct(Product p,String name){ //修改后的产品 p.setName(name); //产生修改事件 new ProductEvent(p,ProductEventType.EDIT_PRODUCT); } //获得是否可以创建一个产品 public boolean isCreateProduct(){ return isPermittedCreate; } //克隆一个产品 public Product clone(Product p){ //产生克隆事件 new ProductEvent(p,ProductEventType.CLONE_PRODUCT); return p.clone(); } } 在每个方法中增加了事件的产生机制，在createProduct方法中增加了创建产品事件，在editProduct方法中增加了修改产品事件，在delProduct方法中增加了遗弃产品事件，在clone方法中增加克隆产品事件，而且每个事件都是通过组合产生的，产品和事件的扩展性非常优秀。刚刚我们说完了产品和事件的关系处理，现在回到我们事件的观察者，它承担着非常重要的职责。我们知道它要处理事件，但是现在还没有想好怎么实现它处理事件的update方法，暂时保持为空。我们继续分析，这么多的事件（现在只有1个产品类，如果产品类很多呢？比如30多个）不可能每个产品事件都写一个处理者吧，对于产品事件来说，它最希望的结果就是我通知了事件处理者（也就是观察者模式的观察者），其他具体怎么处理由观察者来解决，那现在问题是观察者怎么来处理这么多的事件呢？事件的处理者必然有N多个，如何才能通知相应的处理者来处理事件呢？一个事件也可能通知多个处理者来处理，并且一个处理者处理完毕还可能通知其他的处理者，这不可能让每个处理者独自完成这样“不可能完成的任务”，我们把问题的示意图画出来，如图36-4所示。 ![](https://box.kancloud.cn/2016-08-14_57b00370e34bf.jpg) 图36-4 事件处理示意图看到该示意图，你立刻就会想到中介者模式。是的，需要中介者模式上场了，我们把EventDispatch类（嘿嘿，为什么要定义成Dispatch呢？就是分发的意思）作为事件分发的中介者，事件的处理者都是具体的同事类，它们有着相似的行为，都是处理产品事件，但是又有不相同的逻辑，每个同事类对事件都有不同的处理行为。我们来看类图，如图36-5所示。在类图中，EventDispatch类有3个职责。 ● 事件的观察者作为观察者模式中的观察者角色，接收被观察期望完成的任务，在我们的框架中就是接收ProductEvent事件。 ● 事件分发者作为中介者模式的中介者角色，它担当着非常重要的任务——分发事件，并同时协调各个同事类（也就是事件的处理者）处理事件。 ● 事件处理者的管理员角色不是每一个事件的处理者都可以接收事件并进行处理，是需要获得分发者许可后才可以，也就是说只有事件分发者允许它处理，它才能处理。 ![](https://box.kancloud.cn/2016-08-14_57b0037105599.jpg) 图36-5 采用中介者模式对事件进行分发事件分发者担当了这么多的职责，那是不是与单一职责原则相违背了？确实如此，我们在整个系统的设计中确实需要这样一个角色担任这么多的功能，如果强制细分也可以完成，但是会加大代码量，同时导致系统的结构复杂，读者可以考虑拆分这3个职责，然后再组合相关的功能，看看代码量是如何翻倍的。注意　设计原则只是一个理论，而不是一个带有刻度的标尺，因此在系统设计中不应该把它视为不可逾越的屏障，而是应该把它看成是一个方向标，尽量遵守，而不是必须恪守。既然事件分发者这么重要，我们就仔细研读一下它的代码，如代码清单36-7所示。代码清单36-7 事件分发者 public class EventDispatch implements Observer{ //单例模式 private final static EventDispatch dispatch = new EventDispatch(); //事件消费者 private Vector<EventCustomer> customer = new Vector<EventCustomer>(); //不允许生成新的实例 private EventDispatch(){ } //获得单例对象 public static EventDispatch getEventDispatch(){ return dispatch; } //事件触发 public void update(Observable o, Object arg) { //事件的源头 Product product = (Product)arg; //事件 ProductEvent event = (ProductEvent)o; //处理者处理，这里是中介者模式的核心，可以是很复杂的业务逻辑 for(EventCustomer e:customer){ //处理能力是否匹配 for(EventCustomType t:e.getCustomType()){ if(t.getValue()== event.getEventType().getValue()){ e.exec(event); } } } } //注册事件处理者 public void registerCustomer(EventCustomer _customer){ customer.add(_customer); } } 我们在这里使用Vector来存储所有的事件处理者，在update方法中使用了两个简单的for循环来完成业务逻辑的判断，只要事件的处理者级别和事件的类型相匹配，就调用事件处理者的exec方法来处理事件，该逻辑是整个事件触发架构的关键点，但不是难点。请读者注意，在设计这样的框架前，一定要定义好消费者与生产者之间的搭配问题，一般的做法是通过xml文件类或者IoC容器配置规则，然后在框架启动时加载并驻留内存。 EventCustomer抽象类负责定义事件处理者必须具有的行为，首先是每一个事件的处理者都必须定义自己能够处理的级别，也就是通过构造函数来定义自己的处理能力，当然处理能力可以是多值的，也就是说一个处理者可以处理多个事件；然后各个事件的处理者只要实现exec方法就可以了，完成自己对事件的消费处理即可。我们先来看抽象的事件处理者，如代码清单36-8所示。代码清单36-8 抽象的事件处理者 public abstract class EventCustomer { //容纳每个消费者能够处理的级别 private Vector<EventCustomType> customType = new Vector<EventCustomType>(); //每个消费者都要声明自己处理哪一类别的事件 public EventCustomer(EventCustomType _type){ addCustomType(_type); } //每个消费者可以消费多个事件 public void addCustomType(EventCustomType _type){ customType.add(_type); } //得到自己的处理能力 public Vector<EventCustomType> getCustomType(){ return customType; } //每个事件都要对事件进行声明式消费 public abstract void exec(ProductEvent event); } 很简单，我们定义了一个Vector变量来存储处理者的处理能力，然后通过构造函数约束子类必须定义一个自己的处理能力。在代码中，我们用到了事件处理类型枚举，如代码清单36-9所示。代码清单36-9 事件处理枚举 public enum EventCustomType { //新建立事件 NEW(1), //删除事件 DEL(2), //修改事件 EDIT(3), //克隆事件 CLONE(4); private int value=0; private EventCustomType(int _value){ this.value = _value; } public int getValue(){ return value; } } 我们在系统中定义了3个事件处理者，分别是乞丐、平民和贵族。乞丐只能获得别人遗弃的物品，平民消费自己生产的东西，自给自足，而贵族则可以获得精修的产品或者是绿色产品（也就是我们这里的克隆产品，不用自己劳动获得的产品）。我们先看乞丐的源代码，如代码清单36-10所示。代码清单36-10 乞丐 public class Beggar extends EventCustomer { //只能处理被人遗弃的东西 public Beggar(){ super(EventCustomType.DEL); } @Override public void exec(ProductEvent event) { //事件的源头 Product p = event.getSource(); //事件类型 ProductEventType type = event.getEventType(); System.out.println("乞丐处理事件:"+p.getName() +"销毁,事件类型="+type); } } 乞丐在无参构造中定义了自己只能处理删除的事件，然后在exec方法中定义了事件的处理逻辑，每个处理者都是只要完成这两个方法即可，我们再来看平民级别的事件处理者，如代码清单36-11所示。代码清单36-11 平民 public class Commoner extends EventCustomer { //定义平民能够处理的事件的级别 public Commoner() { super(EventCustomType.NEW); } @Override public void exec(ProductEvent event) { //事件的源头 Product p = event.getSource(); //事件类型 ProductEventType type = event.getEventType(); System.out.println("平民处理事件:"+p.getName() +"诞生记,事件类型="+type); } } 平民只处理新建立的事件，其他事件不做处理，我们再来看贵族级别的事件处理者，如代码清单36-12所示。代码清单36-12 贵族 public class Nobleman extends EventCustomer { //定义贵族能够处理的事件的级别 public Nobleman() { super(EventCustomType.EDIT); super.addCustomType(EventCustomType.CLONE); } @Override public void exec(ProductEvent event) { //事件的源头 Product p = event.getSource(); //事件类型 ProductEventType type = event.getEventType(); if(type.getValue() == EventCustomType.CLONE.getValue()){ System.out.println("贵族处理事件:"+p.getName() +"克隆,事件类型="+type); }else{ System.out.println("贵族处理事件:"+p.getName() +"修改,事件类型="+type); } } } 贵族稍有不同，它有两个处理能力，能够处理修改事件和克隆事件，同时在exec方法中对这两类事件分别进行处理。此时，读者可能会想到另外一个处理模式：责任链模式。建立一个链，然后两类事件分别在链上进行处理并反馈结果。读者可以参考一下Servlet的过滤器（Filter）的设计，在框架平台的开发中可以采用该模式，它具有非常好的扩展性和稳定性。所有的角色都已出场，我们建立一个场景类把它们串联起来，如代码清单36-13所示。代码清单36-13 场景类 public class Client { public static void main(String[] args) { //获得事件分发中心 EventDispatch dispatch = EventDispatch.getEventDispatch(); //接受乞丐对事件的处理 dispatch.registerCustomer(new Beggar()); //接受平民对事件的处理 dispatch.registerCustomer(new Commoner()); //接受贵族对事件的处理 dispatch.registerCustomer(new Nobleman()); //建立一个原子弹生产工厂 ProductManager factory = new ProductManager(); //制造一个产品 System.out.println("=====模拟创建产品事件========"); System.out.println("创建一个叫做小男孩的原子弹"); Product p = factory.createProduct("小男孩原子弹"); //修改一个产品 System.out.println("\n=====模拟修改产品事件========"); System.out.println("把小男孩原子弹修改为胖子号原子弹"); factory.editProduct(p, "胖子号原子弹"); //再克隆一个原子弹 System.out.println("\n=====模拟克隆产品事件========"); System.out.println("克隆胖子号原子弹"); factory.clone(p); //遗弃一个产品 System.out.println("\n=====模拟销毁产品事件========"); System.out.println("遗弃胖子号原子弹"); factory.abandonProduct(p); } } 运行结果如下所示： =====模拟创建产品事件======== 创建一个叫做小男孩的原子弹平民处理事件:小男孩原子弹诞生记,事件类型=NEW_PRODUCT =====模拟修改产品事件======== 把小男孩原子弹修改为胖子号原子弹贵族处理事件:胖子号原子弹修改,事件类型=EDIT_PRODUCT =====模拟克隆产品事件======== 克隆胖子号原子弹贵族处理事件:胖子号原子弹克隆,事件类型=CLONE_PRODUCT =====模拟销毁产品事件======== 遗弃胖子号原子弹乞丐处理事件:胖子号原子弹销毁,事件类型=DEL_PRODUCT 我们的事件处理框架已经生效了，有行为，就产生事件，并有处理事件的处理者，并且这三者都相互解耦，可以独立地扩展下去。比如，想增加处理者，没有问题，建立一个类继承EventCustomer，然后注册到EventDispatch上，就可以进行处理事件了；想扩展产品，没问题？需要稍稍修改一下，首先抽取出产品和事件的抽象类，然后再进行扩展即可。