本文主要是介绍一场武林盟主争霸赛-观察者模式PK委托事件技术，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
设计模式中提到观察者模式又叫做发布-订阅（Publish-订阅）模式。它定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有 观察者对象，使它们能够自动更新自己。
C#中提到，委托是对函数的封装，可以当作给方法的特征指定一个名称。而事件则是委托的一种特殊形式，当发生有意义的事情时，事件对象处理通知过程。事件其实就是设计模式中观察者模式在.NET中的一种实现方式。
委托就是一种引用方法的类型。一旦为委托分配了方法，委托将与该方法具有完全相同的行为。委托方法的使用可以像其他任何方法一样，具有参数和返回值。委托可以看作是对函数的抽象，是函数的‘类’，委托的实例将代表一个具体的函数。
只看概念是难以理解的。我们还是拿一个小故事来谈谈两者的联系和区别吧。
武林中，一直是观察者模式称霸一方，后起之秀委托事件技术多次挑衅，挑战霸主之位，到底能不能成功呢？一场武林盟主的争夺即将开始了。
观察者模式方派出代表为甲，委托事件技术方派出代表为 乙。
唇枪舌战比赛正式开始……
甲作为前辈，理应先出招。
甲：“我可以减少两个类之间的耦合，遵循了开放-封闭原则，增加类不需要更改原有代码，并且我还遵循依赖倒转原则，让程序之间各自独立变化，都依赖于抽象。也就是只有Subject和Observer之间有交互。不用管下面具体的类ConcreteSubject和ConcreteObserver是谁。这样我就可以使代码变得非常得灵活，可扩展，可维护、可复用。
当一个对象的改变需要同时改变其他对象的时候，而且它不知道具体有多少对象有待改变时，我是能很好地解决它的。”
乙：“哈哈哈！原来你出道这么些年，就积攒下这么点本事。实话告诉你，你有的我全都有，你没有的我还有。
你难道你没发现你还是有些不足之处吗！尽管你已经用了依赖倒转原则，但是‘抽象通知者'还是依赖’抽象观察者',也就是说，万一没有了抽象观察者这样的接口，我这通知的功能就完不成了。另外就是每个具体观察者，它不一定是‘更新’的方法要调用呀。不同命的方法就不能调用。那我呢，正好弥补了你这个不足，即使通知者和观察者之间根本就互相不知道，那么我只需要用客户端来决定通知谁。
这样的话，我就不要你那抽象观察类了。把你的‘更新’方法改为各自适合的方法名。因为‘抽象通知者‘不希望依赖于’抽象观察者‘，’增加‘和‘减少’的方法就没有必要了。你的门派完全就可以不要了。哈哈哈！
之后我大展身手的时候到了。‘delegate void EventHandler()；’，可以理解为声明了一个特殊的‘类’，而‘public event EventHandler Update'可以理解为声明了一个’类‘的变量。其实就是声明了一个事件委托变量叫‘更新’。这样就使得，本来是在通知者类中的增加和减少的抽象观察者集合以及通知时遍历的抽象观察者都不必要了。转到客户端来让委托搭载多个方法，这就解决了本来与抽象者的耦合问题。
你说，是不是你的门派可以隐退了啊？哈哈哈哈！”
甲：”后起之辈，果然有两把刷子，但别忘了。你再厉害也是有前提的。那就是委托对象所搭载的所有方法必须具有相同的原型和形式，也就是拥有相同的参数列表和返回值类型。“
乙：“不管怎么说，在依赖倒转原则上，我比你做得强！”
甲：“#￥…………#￥……@#”
乙：“#%#￥……%&”
少林寺主持方丈：“两位别争吵了，甲乙英雄，你们一个为前辈，一个为晚辈，互相掐斗 岂不让江湖人笑话！你们都很强，但都有自己的不足之处，但相对来说，还是乙英雄更胜一筹！我宣布今天的武林盟主为：乙英雄！“
委托事件技术方欢呼雀跃，观察模式方叹息：”长江后浪推前浪啊！“
这篇关于一场武林盟主争霸赛-观察者模式PK委托事件技术的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
