设计模式的定义是：在面向对象软件设计过程中针对特定问题的简洁而优雅的解决方案。通俗一点说，设计模式是在某种场合下对某个问题的一种解决方案。如果再通俗一点说，设计模式就是给面向对象软件开发中的一些好的设计取个名字。
在开始敲代码之后，设计模式已经听了很多，总有一个感觉，这是很高大上的东西。其实设计模式不只是代码开发在使用，设计模式是一种思想，适用与任何方面。
亦称： 事件订阅者、监听者、Event-Subscriber、Listener、Observer
观察者模式和发布订阅模式特别容易被人们混淆，很多书里面也将这两个概念混为一谈，所以首先要搞清楚这两种模式的区别。
设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。
有这样一个场景：需要通过定时任务从第三方获取库存数据，拿到库存数据之后，并不是简单的更新数据库，而是需要做至少三个事情：
熟悉消息中间件的同学应该对发布/订阅模式(Publish Subscribe Pattern)并不陌生。即使你不了解消息中间件，那么在平时生活中发布/订阅模式也是非常常见的场景。
面试常常问到设计模式，设计模式在实际业务中即使有用到，但是依然感受不到它的存在，往往在框架中会有更多体现，比如vue2源码，内部还是有很多设计思想，比如观察者模式，模版模式等，我们在业务上一些通用的工具类也会用到单例，在大量的条件判断也会考虑策略者模式，这两种用得比较多。好记性不如烂笔头，又重新回顾了一遍设计模式，虽然仅仅掌握了几种熟悉的设计模式，但是希望在复杂的业务上，能想起那些不太常用的设计模式。
观察者模式又叫做 发布订阅模式，这个设计模式无论在工作还是生活的应用都是非常常见的，但是在我们的代码里面应用场景并不是很多，一般这种设计模式更多的是由 消息中间件进行替代，但是在swing等GUI框架里面可以看到大量的实际使用案例。
不管是手机还是电脑，都是由多个应用程序组成的，应用程序的正常运转，才能带来机器的正常运行。如果平时对手机或者电脑了解比较多的话，就应该知道事件总线设计模式这个概念，那么事件总线设计模式是什么呢？事件总线设计模式可以干什么？
设计模式专题（十）——观察者模式 （原创内容，转载请注明来源，谢谢） 一、概述 观察者模式（Observer），又称做发布-订阅模式（Publish/Subscribe），定义了一种一对多的依赖关系，让多个观察者对象监听同一个主题对象。当主题对象状态变化时，会通知所有观察者对象，让他们能够自动更新自己。 该模式下，将发布者和消费者都设定一个抽象，发布者发布消息，消费者收到消息后会自动进行后续的操作，不同的消费者收到同一个消息，可以有不同的操作。 但是，这样会使得发布者和订阅者之间的耦合度过高，且会使得
今天给大家介绍js中常用的设计模式，也让自己对js设计模式有一个更清晰的认识，下面我们直接进入今日的主题
观察者模式也叫发布订阅模式，定义了对象之间一对多依赖，当一个对象改变状态时，这个对象的所有依赖者都会收到通知并按照自己的方式进行更新。
发布 — 订阅模式，它定义程序对象之间一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖它的对象都将得到通知并执行相应操作。在日常生活中，常见的发布订阅模式有：订阅号，用户关注订阅号，内容创作者在平台发布内容后，平台遍历粉丝列表进行内容推送；销售中介，客户给销售人员留下了客户信息及联系方式，在新产品推出时，挨个给客户打电话进行推销，等等... 而发布订阅模式，一般由三类对象组成：
该文介绍了设计模式及其在JavaScript中的应用，包括单例模式、观察者模式、工厂模式等。
观察者模式定义了对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都将得到通知，并自动更新。观察者模式属于行为型模式，行为型模式关注的是对象之间的通讯，观察者模式就是观察者和被观察者之间的通讯。观察者模式有一个别名叫“发布-订阅模式”，或者说是“订阅-发布模式”，订阅者和订阅目标是联系在一起的，当订阅目标发生改变时，逐个通知订阅者。
在软件开发中，我们经常会遇到需要实现消息传递或事件触发的场景。例如，当用户进行某种操作时，我们需要发送一条消息给其他模块进行处理，或者当某个数据发生了变化时，需要通知其他模块进行更新等。在这些情况下，我们通常会使用设计模式来实现这种机制，其中订阅发布模式就是其中之一。
我们学习设计模式步骤应该是先理解其中的思想，合理使用设计模式，总结经验，融会贯通。
建议先看一下上篇 观察者模式 ，发布订阅模式和观察者模式本质上还是一样的，并且发布订阅模式也没有在经典的设计模式书 GoF 中出现，很多地方也直接把两者看成一种设计模式了。
在软件架构中，发布订阅是一种消息范式，消息的发送者（称为发布者）不会将消息直接发送给特定的接收者（称为订阅者）。而是将发布的消息分为不同的类别，无需了解哪些订阅者（如果有的话）可能存在。同样的，订阅者可以表达对一个或多个类别的兴趣，只接收感兴趣的消息，无需了解哪些发布者（如果有的话）存在。 举个报纸的例子： 还是得说一下报纸，有人说报纸不就是观察者模式，那得有多少观察者和主题？一张报纸那么多板块，订报纸的人那么多，难道要一个人一个人的通知，显然不现实。如果在记者（编辑）和读者之间加了一个载体报纸，那么这还是观察者模式吗？ 无数的编辑将新闻发到报设，报社在将信息整合到报纸同意发送到读者手中，显然这不是观察者模式，观察者模式中，观察者和主题有着很强的耦合性，而在这里显然记者不认识读者，读者也不能通过报纸直接和编辑通信，这就是发布者订阅者模式，简单来说和发布者的区别就是多了一家报社。兴许我这朴实的例子并不能让你看明白，我们看一下国外的大佬怎么说？
微信公众号有服务号、订阅号和企业号之分。以我的公众号为例，我的公众号类型是订阅号，名称是 "小旋锋"，专注于大数据，Java后端类技术分享。目前主要是分享学习笔记为主，尽量做到 "原创"、"高质量"、"成体系"。每当我发布一篇博文推送，订阅的用户都能够在我发布推送之后及时接收到推送，即可方便地在手机端进行阅读。
观察者模式：是一种行为型设计模式。主要关注的是对象的责任，允许你定义一种订阅机制，可在对象事件发生时通知多个"观察"该对象的其他对象。用来处理对象之间彼此交互。
前面介绍了观察者模式，就好比我们去点餐,通知服务员说，餐好了跟我说一下。那么服务员和顾客之间就形成了耦合，首先服务员得知道餐品好了以后通知那些顾客，其次，如果是多位服务员协作，每个服务员都需要知道这些顾客。
“它们是一样的。”，我故作镇定，嘴角露出一丝微笑，仿佛下一秒钟面试官就会给我发offer。
“它们是一样的。”，我故作镇定，嘴角露出一丝微笑，彷佛下一秒钟面试官就会给我发offer。
订阅-发布模式：定义了对象之间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖它的对象都可以得到通知。
无论大家在实践中是否自己实现过观察者模式或监听器模式，但肯定间接使用过。比如Spring的事件机制，大多数人肯定都用过，只是没留意而已。
观察者模式是软件设计中的一种行为模式。它定义了对象之间的一对多关系，其中如果一个对象改变了状态，所有依赖它的对象都会自动被通知并更新。
今天给大家分享一下观察者设计模式（监听设计模式），该模式在很多主流得框架、源码中使用率非常高。在分享之前先给大家讲一个我们使用手机的一个场景，我们都用过手机，当我们手机来电话的时候，会有各种复杂的操作，比如会响铃、手机震动、屏幕会亮屏等等，大家有没有考虑过这个场景是怎么实现的呢？其实这个地方就是使用了观察者设计模式。
本文既有理论知识，又有实用信息：我们将学习每一种具体的模式，为什么以及应该在什么地方使用；然后，我们将看下应用了这些模式的参考架构；接下来，我们将综合运用新学到的模式设计我们的架构；最后，我们将确定选用什么技术实现架构。
本文将介绍微服务架构设计中的设计模式、原则及最佳实践。我们将使用适当的架构设计模式和技术。
观察者模式还算一个比较好玩的设计模式，其实就是发布订阅模式，发布者发布信息，订阅者获取信息，订阅了就能收到信息，没订阅就收不到信息。可以想象成消息中间件在系统中的作用。我认为观察者用的不是很多。
提到设计模式，相信知道的同学都会脱口而出，五大基本原则（SOLID）和 23 种设计模式。SOLID 所指的五大基本原则分别是：单一功能原则、开放封闭原则、里式替换原则、接口隔离原则和依赖反转原则。逐字逐句诠释这五大基本原则违背了写这篇文章的初衷，引用社区大佬的理解，SOLID 可以简单概括为六个字，即“高内聚，低耦合”：
定义：定义一系列的算法，把他们一个个封装起来，并且使他们可以相互替换。把看似毫无联系的代码提取封装、复用，使之更容易被理解和扩展。
这个模式在我们的生活当中非常常见，可以说是几乎所有的媒体平台都用或多或少地用到了这个模式。比如公众号，我们来仔细梳理一下公众号这个平台当中的整个逻辑，会发现其实这里面一共有三方存在，这三方呈一个三角关系。
设计模式是任何优秀软件的基础，JavaScript 也不例外，学习设计模式，对代码组织多一些思路，通过代码片段来学习编码思路对于开发者来说是比较容易理解的，本文继续通过代码片段简单展示常见的设计模式，但不深入设计模式本身。
通过前面一篇集中式缓存的使用教程，我们已经了解了Redis的核心功能：作为K、V存储的高性能缓存。
消息队列（MQ），一种能实现生产者到消费者单向通信的通信模型，这也是现在常用的主流中间件。
常变对象 与不常变对象之间存在依赖关系的前提下，不常变对象 需随 常变对象经常改变逻辑的问题。即解耦 常变对象 与不常变对象之间的依赖关系
2014 年我们发布了 Lambda 服务，掀起了 Serverless 革命。现在越来越多的人谈论 Serverless 的未来。事实上，我们自己构建的应用程序中有一半以上是基于 Lambda 的，Serverless 能够最大限度地利用云计算的价值。现在，越来越多的客户正在决定采用 Serverless。这里，我们不只是在谈论 Lambda、API Gateway、Step Functions 或 EventBridge 等 Serverless 服务，而是如何使用 Serverless 实现快速原型设计、成本可控、高可用、自动扩展以及高效运维，这些都是用户在选择初始应用架构时需要考虑的关键设计因素。
在本文中，我们将学习如何使用设计模式、原则和最佳实践来设计微服务架构。我们将使用正确的架构设计模式和技术。 在本文结束时，您将了解如何在微服务分布式架构上设计系统以实现高可用性、高可扩展性、低延迟和对网络故障的弹性，从而处理数百万个请求。 Event-Driven Architecture 本课程将是软件架构设计的旅程，逐步将架构单片演变为事件驱动的微服务。 我们将从设计处理少量请求的电子商务整体架构开始软件架构的基础知识。 Journey of Design Architectures 之后逐步演
指的是将多个不同的处理模块连接在一起，最后得出一个自己需要的结果的有向无环图（Directed Acyclic Graph/DAG）的系统。
提到设计模式，很多人都会觉得老生常谈，有些人觉得设计模式很有必要，有些人觉得设计模式没那么重要，那么我们在工作中是否应该重视设计模式呢？我们是否应该将设计模式大量应用到我们的生产过程中呢？
今天学习一下用 Go 实现观察者模式，观察者模式主要是用来实现事件驱动编程。事件驱动编程的应用还是挺广的，除了我们都知道的能够用来解耦：用户修改密码后，给用户发短信进行风险提示之类的典型场景，在微服务架构实现最终一致性、实现事件源（A + ES）这些都会用到。
定义：观察者模式是一种行为设计模式， 允许你定义一种订阅机制， 可在对象事件发生时通知多个 “观察” 该对象的其他对象。
观察者模式又叫发布订阅模式（Publish/Subscribe），它定义了一种一对多的关系，让多个观察者对象同时监听某一个主题对象，这个主题对象的状态发生变化时就会通知所有的观察者对象，使得它们能够自动更新自己。
发布/订阅者模式应该是我在开发过程中遇到的最多的设计模式。发布/订阅者模式，也可以称之为消息机制，定义了一种依赖关系，这种依赖关系可以理解为 1对N (注意：不一定是1对多，有时候也会1对1哦)，观察者们同时监听某一个对象相应的状态变换，一旦变化则通知到所有观察者，从而触发观察者相应的事件，该设计模式解决了主体对象与观察者之间功能的 耦合。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
