从命令模式的维度理解Spring 之Application Event

　　Spring的事件(Application Event)为Bean与Bean之间的信息通讯提供了支持。当一个Bean处理完一个任务之后，希望另一Bean指定并能做相应的处理，这时我们就需要让另外一个Bean监听当期Bean所发送的事件。

　　通过上述基本信息可知，Spring的事件需要遵循如下流程：

　　　　(1) 自定义事件，继承ApplicationEvent;

　　　　(2)定义事件监听器，实现ApplicationListener;

　　　　(3)使用容器发布事件。

　　可以理解以上的流程就是Spring默认的事件生效规范。

　　下面简单举例上述规范：

　　　　1、自定义事件

　　　　　　

　　　　2、事件监听器

　　　　　　

　　　　3、事件发布

　　　　　　

　　　　4、配置

　　　　　　

　　　　5、运行

　　　　　　

　　测试结果如下：

　　　　

　　上例中，在事件发布和实际应用运行中都是用到了容器ApplicationContext，这是两个不同的容器其作用也不一样：前者用于事件发布，后者用于bean的装载。通过此例同时验证了spring的功能不仅仅类似装水的容器单一功能，该容器还附带其他功能。就如可以放音乐的冰箱，冰箱本身的功能是保存食物，但是不妨碍制造者制造冰箱时提供其基本功能以外的其他功能。

　　此例中的其他功能Bean之间消息传递使用的Application Event是如何有效工作的呢？上述源码中没有调用事件监听类的迹象，但是实际运行结果确实打印处理监听类中的信息。这里就得从命令设计模式的角度去理解了，实际这只是个人的理解，从理论的角度严格说来具体是否是命令模式待商榷吧(个人理论水平有限)。

　　其UML图如下：

　　　　

　　看似与命令模式没有关联，实际情况是此例中使用的接口都是Spring封装好的，在此图中无法体现。如果将Spring封装好的接口在UML中体现，将是怎样的呢？

　　　　　

　　上图与命令模式的UML图也不尽相同。上图Event作为参数将整个UML图形成一个C型环，而命令模式通过命令接口作为一个对象实现C型环。但是为什么还是可以按照命令模式的逻辑理解呢？因为它们有个共同点：就是发布指令，与执行指令完全没有任何直接的联系。发布指令后，如果不跟踪根本不知道这个指令是怎么执行的——执行过程对外完全屏蔽。对于用户而言，只需发布指令即可，接收者或者监听者无论发生什么变化用户是不可知的；对开发者而言，如果业务发生改变，改变执行该业务接收者或监听者即可。

　　跟踪发现：在Spring中，prepareBeanFactory时，处理Publisher相关内容；Listener创建时，后置处理器，处理监听器的添加；执行具体发布指令的命令时触发监听者执行相关的指令：

　　　　

　　所以，实际上Spring将指令的实际执行者封装在了容器中，而不是如通用的命令模式将Receiver封装在具体的命令中。而ApplicationContext本身就是一个publisher：

　　　　

　　即ApplicationContext进行事件发布时之前，该事件监听者已经进行了注册并与其形参一对多的关系，只待调用：