观察者模式

所谓观察者模式，主要目的是为了松耦合，举一个例子说明，当玩家击杀怪物后可以获得对应的奖励，那么玩家需要关注怪物死亡这一事件，每当怪物死亡的时候，玩家获得奖励的方法就会被调用，玩家需要时刻关注所有的潜在的可能被击杀的怪物，非常的不方便，同时如果怪物的脚本出现了问题也可能影响到玩家的正常操控。我们希望的是，当怪物死亡的时候才让玩家知道“怪物已经死亡了”这个消息，就好比我网购了某样东西，我并不关心货物是怎么送过来，只需要送到之后告诉我“快递到了”这个消息，然后我就会执行取快递这个行为。这样就把我和送快递的流程隔开了。

在上述的例子中，我就是观察者，快递员就是被观察者，快递员送到快递之后就会通知我，然后我执行我的取快递方法。

发布订阅模式

大多数情况下可以将发布订阅模式里的Publisher，理解为观察者模式里的Subject，而Subscriber，就是Observer。区别在于Publisher变化时，并不会主动去通知Subscriber。还是用送快递方式来举例，当快递业务达到一定量的时候，快递员数量不够，送货上门效率就会变低，这个时候就引入了菜鸟驿站的概念，快递员把货物送到菜鸟驿站，顾客去菜鸟驿站取货，两者并不直接接触，而是通过中转站也就是Broker。

快递员告诉菜鸟驿站XXX的快递到了，菜鸟驿站转述给XXX：你的货物到了自取，XXX来到菜鸟驿站：我要取XXX的快递。发布订阅模式里，发布者和订阅者，不是松耦合，而是完全解耦的。从本质上来说发布者和订阅者分别和Broker也是松耦的，但是解耦出来的broker里可以做得更多. 比如:在里面分别对发布者和订阅这使用职责链模式进行执行顺序调整和过滤,以及设置整个链条的终止条件等很多逻辑.

当然采用哪种方式其实和快递的多少并没有直接的联系，需要从发送消息的对象和接受消息的对象做判断，例如 端午节公司发粽子，这件事是由行政部门决定的，公司员工和行政部门同处于公司一个主体下面，这件事不方便交给第三方做，需要亲手交到员工手上，也就是观察者模式。对于送快递来说，顾客与快递员并没有直接联系，也不希望产生过多的纠纷，那么中转站的存在就是合理的。

用C#写一个简单的事件处理中心，代码如下

根据事件的需求，重载不同数量的参数吗(action最多四个参数)，这是一个简单地事件中心的实现。