观察者模式+中介者模式。

有一个产品，他有多个触发事件，他产生的时候触发一个创建事件，修改的时候触发修改事件，删除的时候触发删除事件，这就类似于我们的文本框，初始化（也就是创建）的时候要触发一个onLoad或onCreate事件，修改的时候触发onChange事件，双击（类似于删除）的时候又触发onDbClick事件，我们今天的目标就是来思考怎么实现这样一个架构。

设计都是先易后难，我们先从最简单的部分入手。首先需要一个产品，并且该产品要有创建、修改、销毁的动作，很明显这就是一个工厂方法模式。同时产品也可以通过克隆方式产生，这与我们在GUI设计中经常使用的复制粘贴操作相类似，这非常明显就是原型模式。

我们使用了工厂方法模式创建产品，使用原型模式让对象可以被拷贝，仅仅这两个模式还不足以解决我们的问题，想想看，产品的产生是有一定的条件的，不是谁想产生就产生，否则怎么能够触发创建事件呢？因此需要限定产品的创建者，所以我们把产品和工厂的关系定位为组合关系，而不是简单地聚集或依赖关系。换句话说，产品只能由工厂类创建，而不能被其他对象通过new方式创建，因此我们在这里还用到一个单来源调用（Single Call）方法来解决问题。这是一个方法，不是一个设计模式。

我们先来看产品类的源代码，他比较简单，如下所示。

public class Product implements Cloneable {
	// 产品名称
	private String name;
	// 是否可以属性变更
	private boolean canChanged = false;

	/**
	 * 产生一个新的产品
	 * 
	 * @param manager
	 * @param _name
	 */
	public Product(ProductManager manager, String _name) {
		// 允许建立产品
		if (manager.isCreateProduct()) {
			this.canChanged = true;
			this.name = _name;
		}
	}

	public String getName() {
		return name;
	}

	public void setName(String name) {
		if (this.canChanged) {
			this.name = name;
		}
	}

	@Override
	protected Product clone() {
		Product p = null;
		try {
			p = (Product) super.clone();
		} catch (CloneNotSupportedException e) {
			e.printStackTrace();
		}
		return p;
	}
}

在产品类中，我们只定义产品的一个属性：产品名称（name），并实现了getter/setter方法，然后我们实现了他的clone方法，确保对象是可以被拷贝的。还有一个特殊的地方是我们的构造函数，他怎么会要求传递进来一个工厂对象ProductManager呢？保留你的好奇心，马上为你揭晓答案。我们继续看代码，工厂类如下所示。

public class ProductManager {
	// 是否可以创建一个产品
	private boolean isPermittedCreate = false;

	/**
	 * 建立一个产品
	 * 
	 * @param name
	 * @return
	 */
	public Product createProduct(String name) {
		// 首先修改权限，允许创建
		this.isPermittedCreate = true;
		Product p = new Product(this, name);
		return p;
	}

	/**
	 * 废弃一个产品
	 * 
	 * @param p
	 */
	public void abandonProduct(Product p) {
		// 销毁一个产品，例如删除数据库记录
		p = null;
	}

	/**
	 * 修改一个产品
	 * 
	 * @param p
	 * @param name
	 */
	public void editProduct(Product p, String name) {
		// 修改后的产品
		p.setName(name);
	}

	/**
	 * 获得是否可以创建一个产品
	 * 
	 * @return
	 */
	public boolean isCreateProduct() {
		return this.isPermittedCreate;
	}

	/**
	 * 克隆一个产品
	 * 
	 * @param p
	 * @return
	 */
	public Product clone(Product p) {
		return p.clone();
	}
}

仔细看看工厂类，产品的创建、修改、遗弃、克隆方法都很简单，但有一个方法可不简单——isCreateProduct方法，他的作用是告诉产品类“我是能创建产品的”，注意看我们的程序，在工厂类ProductManager中定义了一个私有变量isCreateProduct，该变量只有在工厂类的createProduct函数中才能设置为true，在创建产品的时候，产品类Product的构造函数要求传递工厂对象，然后判断是否能够创建产品，即使你想使用类似这样的方法：

Product p = new Product(new ProductManager(), "abc");

也是不可能创建出产品的，他在产品中限制必须是当前有效工厂才能生产该产品，而且也只有有效地工厂才能修改产品，看看产品类的canChanged属性，只有他为true时，产品才可以修改，产品就问“你有权力创建我吗”于是工厂类出示了两个证明材料证明自己可以创建产品：一是“我是你的工厂类”，二是“我的isCreateProduct返回true，我有权创建”，于是产品就被创建出来了。这种一个对象只能由固定的对象初始化的方法叫做单来源调用（Single Call）——很简单，但非常有用的方法。

注意：采用单来源调用的两个对象一般是组合关系，两者有相同的生命期，他通常适用于有单例模式和工厂方法模式的场景中。

我们继续往下分析，一个产品新建就要触发事件，那事件是什么？当然也是一个对象了，需要把他设计出来，仅仅有事件还不行，还要考虑有人去处理这个事件，产生了一个事件不可能没有对象去处理吧？如果是这样那事件还有什么意义呢？既然去处理，那就需要一个通知渠道了，于是观察者模式准备好了。

观察者为EventDispatch类，他使用了单例模式，避免对象膨胀，但同时也带来了性能及线程安全隐患，这点需要大家在实际应用中注意（想想Spring中的Bean注入，默认也是单例，在通常的应用中一般不需要修改，除非是较大并发的应用）。我们来看代码，先来看事件类型定义，他是一个枚举类型，如下所示。

public enum ProductEventType {
	// 新建一个产品
	NEW_PRODUCT(1),
	// 删除一个产品
	DEL_PRODUCT(2),
	// 修改一个产品
	EDIT_PRODUCT(3),
	// 克隆一个产品
	CLONE_PRODUCT(4);

	private int vlaue = 0;

	private ProductEventType(int vlaue) {
		this.vlaue = vlaue;
	}

	public int getVlaue() {
		return vlaue;
	}
}

这里定义了4个事件类型，分别是新建、修改、删除以及克隆，比较简单。我们再来看产品的事件，如下所示。

public class ProductEvent extends Observable {
	// 事件起源
	private Product source;
	// 事件的类型
	private ProductEventType type;

	/**
	 * 传入事件的源头，默认为新建类型
	 * 
	 * @param p
	 */
	public ProductEvent(Product p) {
		this(p, ProductEventType.NEW_PRODUCT);
	}

	/**
	 * 事件源头以及事件类型
	 * 
	 * @param p
	 * @param type
	 */
	public ProductEvent(Product p, ProductEventType type) {
		this.source = p;
		this.type = type;
		// 事件触发
		this.notifyEventDispatch();
	}

	/**
	 * 获得事件的始作俑者
	 * 
	 * @return
	 */
	public Product getSource() {
		return source;
	}

	/**
	 * 获得事件的类型
	 * 
	 * @return
	 */
	public ProductEventType getEventType() {
		return this.type;
	}

	/**
	 * 通知事件处理中心
	 */
	private void notifyEventDispatch() {
		super.addObserver(EventDispatch.getEventDispatch());
		super.setChanged();
		super.notifyObservers(source);
	}
}

我们在产品事件类中增加了一个私有方法notifyEventDispatch，该方法的作用是明确事件的观察者，并同时在初始化时通知观察者，他在有参构造中被调用。我们再来看事件的观察者，如下所示。

public class EventDispatch implements Observer {
	// 单例模式
	private final static EventDispatch dispatch = new EventDispatch();
	// 事件消费者
	private Vector<EventCustomer> customer = new Vector<EventCustomer>();

	/**
	 * 不允许生成新的实例
	 */
	private EventDispatch() {
	}

	/**
	 * 获得单例对象
	 * 
	 * @return
	 */
	public static EventDispatch getEventDispatch() {
		return dispatch;
	}

	@Override
	public void update(Observable o, Object arg) {
		
	}

}

产品和事件都定义出来了，那我们想想怎么把这两者关联起来，产品和事件是两个独立的对象，两者都可以独立的扩展，用什么来适应他们的扩展呢？桥梁模式！两个不相关的类可以通过桥梁模式组合出稳定、健壮的结构。

我们这次把抽象化角色和实现角色去掉，各位可能要说了，把抽象化角色和实现化角色去掉，那桥梁模式在抽象层次耦合的优点还怎么体现呢？因为我们采用的是单个产品对象，没有必要进行抽象化处理，若要按照该框架做扩展开发，该部分是肯定需要抽象出接口或抽象类的，好在也非常简单，只要抽取一下就可以了。这样考虑后，我们的ProductManager类就增加一个功能：组合产品类和事件类，产生有意义的产品事件，如下所示。

public class ProductManager {
	// 是否可以创建一个产品
	private boolean isPermittedCreate = false;

	/**
	 * 建立一个产品
	 * 
	 * @param name
	 * @return
	 */
	public Product createProduct(String name) {
		// 首先修改权限，允许创建
		this.isPermittedCreate = true;
		Product p = new Product(this, name);
		// 产生一个创建事件
		new ProductEvent(p, ProductEventType.NEW_PRODUCT);
		return p;
	}

	/**
	 * 废弃一个产品
	 * 
	 * @param p
	 */
	public void abandonProduct(Product p) {
		// 销毁一个产品，例如删除数据库记录
		// 产生删除事件
		new ProductEvent(p, ProductEventType.DEL_PRODUCT);
		p = null;
	}

	/**
	 * 修改一个产品
	 * 
	 * @param p
	 * @param name
	 */
	public void editProduct(Product p, String name) {
		// 修改后的产品
		p.setName(name);
		// 产生修改事件
		new ProductEvent(p, ProductEventType.EDIT_PRODUCT);
	}

	/**
	 * 获得是否可以创建一个产品
	 * 
	 * @return
	 */
	public boolean isCreateProduct() {
		return this.isPermittedCreate;
	}

	/**
	 * 克隆一个产品
	 * 
	 * @param p
	 * @return
	 */
	public Product clone(Product p) {
		// 产生克隆事件
		new ProductEvent(p, ProductEventType.CLONE_PRODUCT);
		return p.clone();
	}
}

在每个方法中增加了事件的产生机制，在createProduct方法中增加了创建产品事件，在editProduct方法中增加了修改产品事件，在delProduct方法中增加了遗弃产品事件，在clone方法中增加克隆产品事件，而且每个事件都是通过组合产生的，产品和事件的扩展性非常优秀。

刚刚我们说完了产品和事件的关系处理，现在回到我们事件的观察者，他承担着非常重要的职责。我们知道他要处理事件，但是现在还没有想好怎么实现他处理事件的update方法，暂时保持为空。

我们继续分析，这么多事件（现在只有1个产品类，如果产品类很多呢？）不可能每个产品事件都写一个处理者吧，对于产品事件来说，他最希望的结果就是我通知了事件处理者（也就是观察者模式的观察者），其他具体怎么处理由观察者来解决，那现在问题是观察者怎么来处理这么多的事件呢？事件的处理者必然有N多个，如何才能通知相应的处理者来处理事件呢？一个事件也可能通知多个处理者来处理，并且一个处理者处理完毕还可能通知其他的处理者，还不可能让每个处理者独自完成这样“不可能完成的任务”。

是的，需要中介者模式上场了，我们把EventDispatch类作为事件分发的中介者，事件的处理者都是具体的同事类，他们有着相似的行为，都是处理产品事件，但是又有不相同的逻辑，每个同事类对事件都有不同的处理行为。

EventDispatch类有3个职责。

• 事件的观察者

作为观察者模式中的观察者角色，接收被观察者期望完成的任务，在我们的框架中就是接收ProductEvent事件。

• 事件分发者

作为中介者模式的中介者角色，他担当着非常重要的任务——分发事件，并同时协调各个同事类（也就是事件的处理者）处理事件。

• 事件处理者的管理员角色

不是每一个事件的处理者都可以接收事件并进行处理，是需要获得分发者许可后才可以，也就是说只有事件分发者允许他处理，他才能处理。

事件分发者担当了这么多的职责，那是不是与单一职责原则相违背了？确实如此，我们在整个系统的设计中确实需要这样一个角色担任这么多的功能，如果强制细分也可以完成，但是会加大代码量，同时导致系统的结构复杂，可以考虑拆分这3个职责，然后再组合相关的功能，看看代码量是如何翻倍的。

注意，设计原则只是一个理论，而不是一个带有刻度的标尺，因此在系统设计中不应该把他视为不可逾越的屏障，而是应该把他看成是一个方向标，尽量遵守，而不是必须恪守。

尽然事件分发者这么重要，我们就仔细研读一下他的代码，如下所示。

public class EventDispatch implements Observer {
	// 单例模式
	private final static EventDispatch dispatch = new EventDispatch();
	// 事件消费者
	private Vector<EventCustomer> customer = new Vector<EventCustomer>();

	/**
	 * 不允许生成新的实例
	 */
	private EventDispatch() {
	}

	/**
	 * 获得单例对象
	 * 
	 * @return
	 */
	public static EventDispatch getEventDispatch() {
		return dispatch;
	}

	@Override
	public void update(Observable o, Object arg) {
		// 事件
		ProductEvent event = (ProductEvent) o;
		// 处理者处理，这里是中介者模式的核心，可以是很复杂的业务逻辑
		for (EventCustomer e : this.customer) {
			// 处理能力是否匹配
			for (EventCustomType t : e.getCustomType()) {
				if (t.getValue() == event.getEventType().getVlaue()) {
					e.exec(event);
				}
			}
		}
	}

	/**
	 * 注册事件处理者
	 * 
	 * @param _customer
	 */
	public void registerCustomer(EventCustomer _customer) {
		this.customer.add(_customer);
	}

}

我们在这里使用Vector来存储所有的事件处理者，在update方法中使用了两个简单地for循环来完成业务逻辑的判断，只要事件的处理者级别和事件的类型相匹配，就调用事件处理者的exec方法来处理事件，该逻辑是整个事件触发架构的关键点，但不是难点。请注意，在设计这样的框架前，一定要定义好消费者与生产者之间的搭配问题，一般的做法是通过xml文件类或者IoC容器配置规则，然后在框架启动时加载并驻留内存。

EventCustomer抽象类负责定义事件处理者必须具有的行为，首先是每一个事件的处理者都必须定义自己能够处理的级别，也就是通过构造函数来定义自己的处理能力，当然处理能力可以是多值的，也就是说一个处理者可以处理多个事件；然后各个事件的处理者只要实现exec方法就可以了，完成自己对事件的消费处理即可。我们先来看抽象的事件处理者，如下所示。

public abstract class EventCustomer {
	// 容纳每个消费者能够处理的级别
	private Vector<EventCustomType> customType = new Vector<EventCustomType>();

	/**
	 * 每个消费者都要声明自己处理哪一类别的事件
	 * 
	 * @param customType
	 */
	public EventCustomer(EventCustomType customType) {
		addCustomType(customType);
	}

	/**
	 * 每个消费者可以消费多个事件
	 * 
	 * @param type
	 */
	public void addCustomType(EventCustomType type) {
		this.customType.add(type);
	}

	/**
	 * 得到自己的能力
	 * 
	 * @return
	 */
	public Vector<EventCustomType> getCustomType() {
		return customType;
	}

	/**
	 * 每个事件都要对事件进行声明式消费
	 * 
	 * @param event
	 */
	public abstract void exec(ProductEvent event);
}

很简单，我们定义了一个Vector变量来存储处理者的处理能力，然后通过构造函数约束子类必须定义一个自己的处理能力。在代码中，我们用到了事件处理类型枚举，如下所示。

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个事件处理者，分别是乞丐、平民和贵族。乞丐只能获得别人遗弃的物品，平民消费自己生产的东西，自给自足，而贵族则可以获得精修的产品或者是绿色产品（也就是我们这里的克隆产品，不用自己劳动获得的产品）。我们先看乞丐的源代码，如下所示。

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方法中定义了事件的处理逻辑，每个处理者都是只要完成这两个方法即可，我们再来看平民级别的事件处理者，如下所示。

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);
	}

}

平民只处理新建立的事件，其他事件不做处理，我们再来看贵族级别的事件处理者，如下所示。

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.getVlaue() == EventCustomType.CLONE.getValue()) {
			System.out.println("贵族处理事件：" + p.getName() + "克隆，事件类型=" + type);
		} else {
			System.out.println("贵族处理事件：" + p.getName() + "修改，事件类型=" + type);
		}
	}

}

贵族稍有不同，他有两个处理能力，能够处理修改事件和克隆事件，同时在exec方法中对这两类事件分别进行处理。此时，可能会想到另外一个处理模式：责任链模式。建立一个链，然后两类事件分别在链上进行处理并反馈结果。可以参考一下Servlet的过滤器的设计，在框架平台的开发中可以采用该模式，他具有非常好的扩展性和稳定性。

所有的角色都已出场，我们建立一个场景类把他们串联起来，如下所示。

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);
	}
}

我们的事件处理框架已经生效了，有行为，就产生事件，并有处理事件的处理者，并且这三者都相互解耦，可以独立的扩展下去。比如，想增加处理者，没有问题，建立一个类继承EventCustomer，然后注册到EventDispatch上，就可以进行处理事件了；想扩展产品，没问题？需要稍稍修改一下，首先抽取出产品和事件的抽象类，然后再进行扩展即可。

小结

该事件触发框架结构清晰，扩展性好，可以进行抽象化处理后应用于实际开发中。我们回头看看在这个案例中使用了哪些设计模式。

• 工厂方法模式

负责产生产品对象，方便产品的修改和扩展，并且实现了产品和工厂的紧耦合，避免产品随意被创建而无触发事件的情况发生。

• 桥梁模式

在产品和事件两个对象的关系中我们使用了桥梁模式，如此设计后，两者都可以自由的扩展（前提是需要抽取抽象化）而不会破坏原有的封装。

• 观察者模式

观察者模式解决了事件如何通知处理者的问题，而且观察者模式还有一个优点是可以有多个观察者，也就是我们的架构是可以多层级、多分类的处理者。想重新扩展一个新类型（新接口）的观察者？没有问题，扩展ProductEvent即可。

• 中介者模式

事件有了，处理者也有了，这些都会发生变化，并且处理者之间也有耦合关系，中介者则可以完美的处理这些复杂的关系。

我们再来思考一下，如果我们要扩展这个框架，可能还会用到什么模式？首先是责任链模式，他可以帮助我们解决一个处理者处理多个事件的问题；其次是模板方法模式，处理者的启用、停用等，都可以通过模板方法模式来好似西安；再次是装饰模式，事件的包装、处理者功能的强化都会用到装饰模式。当然了，我们还可能用到其他的模式，只要能够很好的解决我们的困境，那就好好使用吧，这也是我们学习设计模式的目的。