网站效果图尺寸,网络服务公司,网站建设电子合同模板,网站建设推广seo前言观察者模式的大名#xff0c;想必各位看官早已有所耳闻。从我们现实生活来说#xff0c;微信公众号订阅、医院挂号叫号等都属于它的实际应用。在程序世界中#xff0c;它是一种用于将代码解耦的设计模式#xff0c;如果你想掌握并理解这种设计模式#xff0c;今天就和… 前言观察者模式的大名想必各位看官早已有所耳闻。从我们现实生活来说微信公众号订阅、医院挂号叫号等都属于它的实际应用。在程序世界中它是一种用于将代码解耦的设计模式如果你想掌握并理解这种设计模式今天就和我一起来探究它的奥秘之处吧观察者模式在前文讲述事件机制时我们其实已经提到了观察者模式。观察者模式事实上实现了一种通讯机制也就是观察目标对观察者进行通知的机制。在基于低耦合的设计前提下观察者无需直接调用观察目标的内部方法或属性获取通知而是使用“订阅”的方式获取通知大体的流程图如下结合实际开发例子来说在C#中我们只需要定义相应的委托和事件即可实现观察者模式的使用详细使用方法可以参考我之前的文章内容再谈C#中的委托和事件在此不再赘述。但在其他语言中例如Java本身未提供类似委托或事件的机制进行回调因此在实现方面会略微繁琐一些相关类图如下在这种实现方式中我们需要对观察目标也就是发布主题进行一个抽象即图中的Subject用于提供保存观察者的集合(图中的ArrayList)以及对观察者的增加或删除的方法。而在具体主题(图中的ConcreteSubject)中包含了状态属性以及状态变化的方法在自身发生变化时会调用notifyObserver方法进行通知。在观察者的实现中也存在抽象观察者(Observer)和具体观察者(ConcreteObserver)两种角色。前者一般定义一个接口用于在接收到变化通知时对自身进行更新。而后者会实现具体的update方法类似C#中我们订阅事件之后触发的回调方法。以上就是我们在两种语言中分别实现观察者模式的方式正如软件工程强调的“没有银弹”的说法观察者模式虽然解决了很多问题但也存在部分缺点主要内容如下1、观察者数量很多时逐个通知会非常耗时。正如我们上述实现存在一个ArrayList来保存所有的观察者如果这个ArrayList中的元素足够大那么在通知时程序的执行效率势必是很低下的。2、如果观察目标与观察者之间存在循环依赖时观察者模式会触发双方的循环调用导致系统崩溃。3、缺乏相应的机制通知观察者观察目标是如何发生变化的观察者仅仅是得知观察目标发生了变化。当然这一点也不是绝对的我们在程序实现时可以通过传递参数或者对象的方式去“告知”观察者观察目标发生了哪些变化。我们在讲述观察者模式时反复提到了“主题”和“订阅”的概念。从概念上理解而言似乎观察者模式就是发布-订阅模式那么两者之间究竟有没有区别呢我们一起进入下一章节来继续探究。发布订阅模式事实上发布订阅模式和观察者模式是有区别的。回到我们最开始的例子微信公众号的订阅看似是直接关注了公众号实质上在关注和推送的两种行为中都是要通过“微信公众平台”这个第三方来实现的。看到这里聪明的各位应该可以理解到发布订阅模式的不同之处没错发布订阅模式是在观察者模式的基础上加入了“事件中心”的概念通过事件中心发布者和订阅者进行了进一步的解耦发布者无需关心订阅者的订阅情况而是直接发布主题到事件中心即可。而订阅者也无需关心发布者自身的情况甚至不知道发布者是何人只需要接收事件中心的通知即可。发布订阅模式在目前的各种消息中间件中应用非常广泛如常见的RabbitMQkafka等发布者发布主题消费者订阅对应的主题对发布的消息进行消费相信大家对这些概念并不陌生。小结至此我们今天要探究的主题就暂时告一段落。观察者模式与发布订阅模式如此相似但又有所不同在我们理清各自的概念和实现方式后又会发现在我们日常的应用中这两种模式无所不在。设计模式本身就是一些优秀的前辈在开发过程中对一些最佳实践和方法论做出的沉淀和总结所以大家在提到这些内容时不要先入为主的认为这些东西只是停留在概念阶段无法落地实践。而是需要结合自己的实际工作仔细思考设计模式该如何应用如何选择合适的设计模式解决自己遇到的问题。当然永远没有最优的方案滥用设计模式只会大大降低程序的可读性对后续维护造成困难。活学活用在这里祝愿大家可以和我一起学习共同进步和成长我们下期再见
