关于事件通知设计模式的信息

本篇文章给大家谈谈事件通知设计模式，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享事件通知设计模式的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、iOS 设计模式（五）-KVO 详解
• 2、设计模式（五）行为型模式
• 3、java设计模式-回调、事件监听器、观察者模式
• 4、系统架构设计模式

iOS 设计模式（五）-KVO 详解

KVO 事件通知设计模式的全称是 Key-Value Observing，俗称“键值观察/监听”，是苹果提供的一套事件通知机制，允许一个对象观察/监听另一个对象指定属性值的改变。当被观察对象属性值发生改变时，会触发 KVO 的监听方法来通知观察者。KVO 是在 MVC 应用程序中的各层之间进行通信的一种特别有用的技术。
KVO 和 NSNotification 都是 iOS 中观察者模式的一种实现。
KVO 可以监听单个属性的变化，也可以监听集合对象的变化。监听集合对象变化时，需要通过 KVC 的 mutableArrayValueForKey: 等可变代理方法获得集合代理对象，并使用代理对象进行操作，当代理对象的内部对象发生改变时，会触发 KVO 的监听方法。集合对象包含 NSArray 和 NSSet 。

先创建一个类，作为要监听的对象。

监听实现

KVO 主要用来做键值观察操作，想要一个值发生改变后通知另一个对象，则用 KVO 实现最为合适。斯坦福大学的 iOS 教程中有一个很经典的案例，通过 KVO 在 Model 和 Controller 之间进行通信。如图所示事件通知设计模式：

KVO 触发分为自动触发和手动触发两种方式。

如果是监听对象特定属性值的改变，通过以下方式改变属性值会触发 KVO事件通知设计模式：

如果是监听集合对象的改变，需要通过 KVC 的 mutableArrayValueForKey: 等方法获得代理对象，并使用代理对象进行操作，当代理对象的内部对象发生改变时，会触发 KVO。集合对象包含 NSArray 和 NSSet 。

普通对象属性或是成员变量使用：

NSArray 对象使用：

NSSet 对象使用：

observationInfo 属性是 NSKeyValueObserving.h 文件中系统通过分类给 NSObject 添加的属性，所以所有继承于 NSObject 的对象都含有该属性；
可以通过 observationInfo 属性查看被观察对象的全部观察信息，包括 observer 、 keyPath 、 options 、 context 等。

注册方法 addObserver:forKeyPath:options:context: 中的 context 可以传入任意数据，并且可以在监听方法中接收到这个数据。

context 作用：标签-区分，可以更精确的确定被观察对象属性，用于继承、 多监听；也可以用来传值。
KVO 只有一个监听回调方法 observeValueForKeyPath:ofObject:change:context: ，事件通知设计模式我们通常情况下可以在注册方法中指定 context 为 NULL ，并在监听方法中通过 object 和 keyPath 来判断触发 KVO 的来源。

但是如果存在继承的情况，比如现在有 Person 类和它的两个子类 Teacher 类和 Student 类，person、teacher 和 student 实例对象都对象的 name 属性进行观察。问题：
当 name 发生改变时，应该由谁来处理呢？
如果都由 person 来处理，那么在 Person 类的监听方法中又该怎么判断是自己的事务还是子类对象的事务呢？
这时候通过使用 context 就可以很好地解决这个问题，在注册方法中为 context 设置一个独一无二的值，然后在监听方法中对 context 值进行检验即可。

苹果的推荐用法：用 context 来精确的确定被观察对象属性，使用唯一命名的静态变量的地址作为 context 的值。可以为整个类设置一个 context ，然后在监听方法中通过 object 和 keyPath 来确定被观察属性，这样存在继承的情况就可以通过 context 来判断；也可以为每个被观察对象属性设置不同的 context ，这样使用 context 就可以精确的确定被观察对象属性。

context 优点：嵌套少、性能高、更安全、扩展性强。
context 注意点：

KVO 可以监听单个属性的变化，也可以监听集合对象的变化。监听集合对象变化时，需要通过 KVC 的 mutableArrayValueForKey: 等方法获得代理对象，并使用代理对象进行操作，当代理对象的内部对象发生改变时，会触发 KVO 的监听方法。集合对象包含 NSArray 和 NSSet 。（注意：如果直接对集合对象进行操作改变，不会触发 KVO。）

可以在被观察对象的类中重写 + (BOOL)automaticallyNotifiesObserversForKey:(NSString *)key 方法来控制 KVO 的自动触发。

如果我们只允许外界观察 person 的 name 属性，可以在 Person 类如下操作。这样外界就只能观察 name 属性，即使外界注册了对 person 对象其它属性的监听，那么在属性发生改变时也不会触发 KVO。

也可以实现遵循命名规则为 + (BOOL)automaticallyNotifiesObserversOf<Key 的方法来单一控制属性的 KVO 自动触发，<Key 为属性名（首字母大写）。

使用场景：
使用 KVO 监听成员变量值的改变；
在某些需要控制监听过程的场景下。比如：为了尽量减少不必要的触发通知操作，或者当多个更改同时具备的时候才调用属性改变的监听方法。

由于 KVO 的本质，重写 setter 方法来达到可以通知所有观察者对象的目的，所以只有通过 setter 方法或 KVC 方法去修改属性变量值的时候，才会触发 KVO，直接修改成员变量不会触发 KVO。
当我们要使用 KVO 监听成员变量值改变的时候，可以通过在为成员变量赋值的前后手动调用 willChangeValueForKey: 和 didChangeValueForKey: 两个方法来手动触发 KVO，如：

NSKeyValueObservingOptionPrior （分别在值改变前后触发方法，即一次修改有两次触发）的两次触发分别在 willChangeValueForKey: 和 didChangeValueForKey: 的时候进行的。
如果注册方法中 options 传入 NSKeyValueObservingOptionPrior ，那么可以通过只调用 willChangeValueForKey: 来触发改变前的那次 KVO，可以用于在属性值即将更改前做一些操作。

有时候我们可能会有这样的需求，KVO 监听的属性值修改前后相等的时候，不触发 KVO 的监听方法，可以结合 KVO 的自动触发控制和手动触发来实现。

例如：对 person 对象的 name 属性注册了 KVO 监听，我们希望在对 name 属性赋值时做一个判断，如果新值和旧值相等，则不触发 KVO，可以在 Person 类中如下这样实现，将 name 属性值改变的 KVO 触发方式由自动触发改为手动触发。

有些情况下我们想手动观察集合属性，下面以观察数组为例。
关键方法：

需要注意的是，根据 KVC 的 NSMutableArray 搜索模式：

有些情况下，一个属性的改变依赖于别的一个或多个属性的改变，也就是说当别的属性改了，这个属性也会跟着改变。
比如我们想要对 Download 类中的 downloadProgress 属性进行 KVO 监听，该属性的改变依赖于 writtenData 和 totalData 属性的改变。观察者监听了 downloadProgress ，当 writtenData 和 totalData 属性值改变时，观察者也应该被通知。以下有两种方法可以解决这个问题。

以上两个方法可以同时存在，且都会调用，但是最终结果会以 keyPathsForValuesAffectingValueForKey: 为准。

以上方法在观察集合属性时就不管用了。例如，假如事件通知设计模式你有一个 Department 类，它有一个装有 Employee 类的实例对象的数组，Employee 类有 salary 属性。你希望 Department 类有一个 totalSalary 属性来计算所有员工的薪水，也就是在这个关系中 Department 的 totalSalary 依赖于所有 Employee 实例对象的 salary 属性。以下有两种方法可以解决这个问题。

有时候我们难以避免多次注册和移除相同的 KVO，或者移除了一个未注册的观察者，从而产生可能会导致 Crash 的风险。
三种解决方案： 黑科技防止多次添加删除KVO出现的问题

我们在对象添加监听之前分别打印对象类型

我们看到，添加监听后，使用 object_getClass 方法获取model类型时获取到的是 NSKVONotifying_DJModel 。

这里就产生了几个问题：

从打印结果可以看出， NSKVONotifying_DJModel 是 DJModel 的子类，说明我们添加了监听之后动态创建了一个 DJModel 的子类 NSKVONotifying_DJModel ，并将对象 DJModel 的类型更改为了 NSKVONotifying_DJModel 。

我们从源码看出，实例对象调用 class 方法会返回 isa 指针，类对象调用 class 方法会返回自己，通过 object_getClass 方法获取对象的类型也会返回 isa 指针。从源码上看model对象添加监听之后使用 class 和使用 object_getClass 方法获取到的类型应该是一样的，但是这里却不同，我们猜测在添加了监听之后在 NSKVONotifying_DJModel 中重写了 class 方法。
我们打印一下添加监听前后 class 方法的 IMP 地址来确认是否重写了 class 方法。

从打印结果可以看出，添加监听之后 class 方法的地址改变了，这验证了我们之前的猜想， NSKVONotifying_DJModel 类中重写了 class 方法。

我们监听对象时调用了 set 方法，我们对监听前后的 set 方法单独分析。
我们再添加监听前后分别打印 setName 方法的 IMP 地址。

通过打印结果可以看出 setName 方法也在 NSKVONotifying_DJModel 中被重写了，我们再使用lldb来看下 setName 具体是什么

第一个地址打印的是添加监听前 setName 方法的 IMP 地址，第二个打印的是添加监听后 setName 方法的 IMP 地址。
这里看出添加监听前 setName 对应的具体方法就是 setName ，但是添加监听后， setName 对应的鸡头方法却变成了 _NSSetObjectValueAndNotify 函数。
下面我们就来研究一下 _NSSetObjectValueAndNotify 函数。

从上面与KVO相关的方法中我们可以看出，每一种数据类型都对应了一个 setXXXValueAndNotify 函数。
不过这些函数的具体实现没有公布，所以内部构造这里还是不清楚。
但是我们知道，在调用 `setXXXValueAndNotify 函数的过程中会调用另外两个方法。

测试后得出了以下几个结论：

我们还可以利用这两个方法手动触发 observeValueForKeyPath 方法：

所以我们判断在 _NSSetObjectValueAndNotify 函数内部，在调用原来的 set 方法之前插入了 willChangeValueForKey 方法，在调用原来的 set 方法之后插入了 didChangeValueForKey 方法，并根据初始化时的枚举值决定调用 observeValueForKeyPath 的时机。

（1）添加监听时，会动态创建一个监听对象类型的子类，并将监听对象的 isa 指针指向新的子类。
（2）子类中重写了 class 和监听属性的 set 方法。
（3）重写 class 方法是为了不将动态创建的类型暴露出来。
（4）重写 set 方法是将 set 方法的具体实现替换成了与属性类型相关的 __NSSetXXXValueAndNotify 函数。
（5）在 __NSSetXXXValueAndNotify 函数内部在 set 方法前后分别插入了 willChangeValueForKey 和 didChangeValueForKey 这两个方法。
（6）根据添加监听时的枚举值决定调用 observeValueForKeyPath 的具体时机。

设计模式（五）行为型模式

在上一篇结构型模式中，我们以功能为基本单位，研究了一些设计模式，用于实现功能转换、功能组合、功能封装等目的。

我们知道，面向对象编程有两个核心元素：对象、对象间通信协作。从面向对象的角度看，任何系统和功能，都是由一个个对象，相互分工合作实现的。推而广之，很多系统也都是这样组织和运行的。

本章的设计模式，列举了通用场景下常用功能机制的经典实现方法，讲解了经典实现中是如何高效组织对象、控制对象协作交互的，具有很好的参考价值。

示例：https://www.runoob.com/design-pattern/chain-of-responsibility-pattern.html

责任链模式，就是把程序处理对象前后排列起来，形成一条处理线。处理线上需要被处理的信息，在处理线上向下传递，任何一个节点都可以随时中断传递。

GUI系统中的事件传递机制（在Javascript中叫做事件冒泡），是责任链模式最典型的应用之一。

当某一事件发生时，最顶层GUI对象会首先收到事件，但是它先不处理，而是依次交给命中的子GUI对象处理。当子GUI对象返回为False时，表示事件未被接收，此时父GUI对象才真正对发生的事件进行业务处理。

可以看出，事件传递机制，是一种增强版的责任链模式，它的节点处理权，经历了向下和向上的双向传递过程。

总结：当项目中一个数据对象，需要被多个处理对象进行处理时，可以将处理对象链接起来，然后把数据对象传递给头节点，随着处理的进行，数据对象的处理权会在处理链中流动，从而完成整个处理过程。

责任链模式结构适用于需求固定的场景，用于实现简单高效的处理机制。假如需求不断变化，而且功能很复杂，那么用责任链模式很可能就无法胜任了，需要采用新的高复杂度的设计。例如，如果想要数据对象在所有处理对象中根据状态来实现跳转，可以选择使用状态机等其他方案来实现。

示例：https://www.runoob.com/design-pattern/command-pattern.html

想要实现撤销、重做、事务等功能，可以使用此设计模式。通常在编辑器、数据库中有此类功能需求。

命令也就是请求，或者叫调用。命令模式要求将请求参数和请求相关的方法封装在一起。

请求对象中封装了实现“撤销”、“重做”、“事务”功能所需要的所有信息，实现了关联信息的高内聚，所以可以实现我们想要的功能。

例如，可以在请求对象中保存修改之前的值、修改之后的值。利用修改之前的值，可以实现“撤销”功能；利用修改之后的值，可以实现“重做”功能。如果将所有请求对象都记录下来，并按照先后顺序排列起来，形成“撤销重做”堆栈，这样就可以实现连续的“撤销”、“重做”。“事务”则是“撤销”与“重做”的结合体，正常执行流程等同于“重做”，发生错误需要回滚，等同于“撤销”。

如果不采用这种方式，会导致实现这些功能的信息，分散在源码中多个地方，或者已经丢失，没有保存，就无法实现“撤销”、“重做”、“事务”功能。

同时，实现请求参数高内聚，也可以很方便地将它们保存到磁盘上，保存到文件的过程叫做“序列化”，从文件中读取的过程叫“反序列化”。这里的序列指的就是二进制流。

Qt中与命令模式相关的部分是：Undo Framework，里面有示例项目，不熟悉的同学可以抽点时间看一看。

示例：https://www.runoob.com/design-pattern/interpreter-pattern.html

顾名思义，解释器模式是用来实现解释器的。 解释器是这样一个程序：解释器以符合语法的文本为输入，解释输入内容，完成一定的计算功能。文本可以在程序运行时动态加载，动态解释、动态执行。

实现简单的解释器：命令行程序，如ping命令、cd命令等； 实现复杂的解释器：脚本语言解释器，如python，lua，javascript；计算器。

我们知道，在GUI图形用户界面被发明之前，人类和程序之间的交互是通过敲命令行实现的，缺点是使用难度较大，门槛较高。 在GUI发明以后，交互更加友好，电脑更加易于使用了，所以也更加普及了。

但是GUI交互的缺点在于，不够灵活，对参数的控制粒度不够细致。例如，现在大多数开发者都使用集成开发环境来开发软件，一般情况下都使用默认参数，比较方便。但是如果你想要更改某些编译选项，可能还是需要直接修改底层的编译命令。命令相对于GUI元素更加灵活，过于灵活的地方用GUI比较难于实现，例如组合、递归、跳转等等。在这些场景下，使用解释器是非常合适的。但是通常情况下，这个模式并不常用。

示例：https://www.runoob.com/design-pattern/iterator-pattern.html

在需要多次遍历同一个数据集合的时候，为了少些一些for，或者想要把遍历过程封装起来，降低耦合，就可以使用迭代器模式。这个模式非常常用。

迭代器就是一个专门用来遍历数组的类。它只需要实现两个接口：hasNext()、next()。 hasNext()接口用于控制循环何时停止；next()接口用于取出当前位置的数据元素，并将遍历指针指向下一个元素。 当然，构造迭代器对象的时候，需要将数据集合传递给迭代器，让迭代器知道要遍历哪些数据。

原本需要用for循环来遍历的代码，现在通过封装，提取出了“遍历”这一功能所需要的必要信息，定义了两个接口，把不必要暴露的信息封装在了迭代器中，妥妥的实现了解耦。

示例：https://www.runoob.com/design-pattern/mediator-pattern.html

中介者模式是指，在原本直接通信的对象之间，添加一个通信中间层，使对象间通信变为间接通信，降低对象间的耦合。

此模式和代理模式基本思想上是一致的。二者的区别是：代理模式是通过加一个中间层，来实现两个原本很难交互的功能主体，实现顺畅交互；中介者模式是为了降低对象间通信时的耦合而提出的，为的是提高代码的可维护性。

比较大的项目中会用到，一般存在于某些框架中。因为大的项目中对象繁多，通信也比较复杂，适合使用中介者模式。

在大的项目中，一般会有一个全局的通信管理器，任何对象都可以使用通信管理器提供的接口，将自己注册为某一个具有唯一ID消息的发送者和接收者。这样发送者只需要发送消息，不需要管谁来接收，不需要拥有发送者的实例指针，发出消息后，已注册的接收者都会收到消息。接收者不需要管信号是谁发的，即不需要拥有发送者的实例指针。

所以，中介者模式也可以叫“通信中介模式”。

示例：https://www.runoob.com/design-pattern/memento-pattern.html

这个模式和状态存档功能是绑定在一起的。为了在程序中实现状态存档功能，可以使用备忘录模式。

原例子中有三个类，个人觉得没有必要，这里我们简化成两个类，即备忘录模式中有两个类：状态对象类和状态对象管理类。 状态对象类是状态字段是集合，并提供了存取接口；状态对象管理类负责组织和保存状态对象。当然实际实现中可以根据需求增加类，配合使用，完成状态保存恢复。

当一个对象会影响到其他多个对象时，即当对象间存在一对多关系时，使用观察者模式。 一般应用于单向通知的场景，如GUI中鼠标事件、按键事件、窗口事件通知。使用Qt中的信号槽机制可以实现此模式。

“一”是指发生变化的那个对象，“多”是指需要获取此变化通知的对象组。其中，变化消息是单向地由“一”到“多”传递的。如果不是单向的或者对象间不是一对多的关系，更加复杂，就需要重新思考其他对象间通信模型。

如果不使用此模式，可能会导致观察者不能动态增加或删除；可能会造成发送者的业务代码和接收者的响应代码混在一起，耦合严重。

使用此模式，需要为观察者设计一个基类，并设计一个接收通知的接口，所有观察者需要实现通知接口；所有观察者指针可以保存在队列中，实现动态增删。

状态模式用于实现状态机。 如果一个程序功能中存在某些状态，在一定情况下，这些状态可以互相转换，并且在转换前后需要作出对应的操作，这种情况下使用状态机来实现就非常合适。

如果不使用状态机（状态模式），一般的实现方法是使用一连串的if-else，或者使用长长的switch-case来实现。这样做的缺点，一方面状态判断不够高效，另一方面是业务代码集中在一块，不好维护。

使用状态机，每个状态都是一个类，相关的业务代码分布到各自的状态类中，能够实现不同的状态及与状态相关的业务代码解耦。同时某个状态和下一个状态是关联好的，在状态切换时，效率更高，不需要执行长长的判断。

Qt中已实现状态机框架，The State Machine Framework，在此框架下，我们可以更加专注于业务实现，而不是状态机本身的技术细节。

示例：https://www.runoob.com/design-pattern/null-object-pattern.html

使用基类保存子类对象通常有两种做法：

第一种方法用指针是基本方法，但是指针用起来要非常小心，要考虑内存释放的问题。此时空对象就可以用空指针表示。 第二种方法用基类对象保存子类对象，这种方法使用起来相对省心，不用与指针打交道，使用者不用直接管理内存。例如Qt中的Qt XML C++ Classes类的设计就是采用这种方式设计的。这种情况下，因为不使用指针，就需要使用空对象来代替空指针。

可以仿造Qt XML中的类进行设计。一般需要提供isNull()接口，对象类型转换接口等。

策略模式和桥接模式类似，用于实现功能切换与组合。二者区别在于，策略模式专注于一个功能的不同实现方式；桥接模式专注于多个功能之间的组合。

将功能抽象成单独的类，功能切换只需要切换不同的功能子类即可，同一个功能需要实现同一个功能接口。

示例：https://www.runoob.com/design-pattern/template-pattern.html

模板模式应该是我们最熟悉的。 这里的模板就是接口类，接口类定义了使用者和功能提供者之间交互的函数列表。子类负责功能的具体实现。

示例：https://www.runoob.com/design-pattern/visitor-pattern.html

访问者模式用于将数据结构与数据操作相分离。

访问者模式和迭代器模式类似。迭代器模式一般用来遍历数组，所以没有把for封装起来。而访问者模式可以遍历一切类型的数据结构，具体的遍历过程被封装在接收者内部。同时，对每一个遍历得到的数组元素的操作，被封装在访问者内部。每一种对元素不同的操作，都需要新建一个访问者类。

接收者需要实现accept()接口，访问者需要实现visit()接口。

每种设计模式都有使用场景，都有优点和缺点。随着需求的改变，任何一种设计模式可能都将不再适用。

java设计模式-回调、事件监听器、观察者模式

转自( https://my.oschina.net/u/923324/blog/792857 )

背景
关于设计模式，之前笔者写过工厂模式，最近在使用gava ListenableFuture时发现事件监听模型特别有意思，于是就把事件监听、观察者之间比较了一番，发现这是一个非常重要的设计模式，在很多框架里扮演关键的作用。

回调函数
为什么首先会讲回调函数呢？因为这个是理解监听器、观察者模式的关键。

什么是回调函数
所谓的回调，用于回调的函数。 回调函数只是一个功能片段，由用户按照回调函数调用约定来实现的一个函数。 有这么一句通俗的定义：就是程序员A写了一段程序（程序a），其中预留有回调函数接口，并封装好了该程序。程序员B要让a调用自己的程序b中的一个方法，于是，他通过a中的接口回调自己b中的方法。

举个例子：
这里有两个实体：回调抽象接口、回调者（即程序a）

回调接口（ICallBack ）
public interface ICallBack {
public void callBack();
}
回调者（用于调用回调函数的类）
public class Caller {

}
回调测试：
public static void main(String[] args) {
Caller call = new Caller();
call.call(new ICallBack(){

控制台输出：

start...

终于回调成功了！

end...

还有一种写法

或实现这个ICallBack接口类

class CallBackC implements ICallBack{
@Override
public void callBack() {
System.out.println("终于回调成功了！");
}
}
有没有发现这个模型和执行一个线程，Thread很像。 没错，Thread就是回调者，Runnable就是一个回调接口。

new Thread(new Runnable(){
@Override
public void run() {
System.out.println("回调一个新线程！");
}}).start();
Callable也是一个回调接口，原来一直在用。 接下来我们开始讲事件监听器

事件监听模式
什么是事件监听器
监听器将监听自己感兴趣的事件一旦该事件被触发或改变，立即得到通知，做出响应。例如：android程序中的Button事件。

java的事件监听机制可概括为3点：

java的事件监听机制涉及到 事件源，事件监听器，事件对象 三个组件,监听器一般是接口，用来约定调用方式
当事件源对象上发生操作时，它将会调用事件监听器的一个方法，并在调用该方法时传递事件对象过去
事件监听器实现类,通常是由开发人员编写，开发人员通过事件对象拿到事件源，从而对事件源上的操作进行处理
举个例子
这里我为了方便，直接使用jdk，EventListener 监听器，感兴趣的可以去研究下源码，非常简单。

监听器接口
public interface EventListener extends java.util.EventListener {
//事件处理
public void handleEvent(EventObject event);
}

事件对象
public class EventObject extends java.util.EventObject{
private static final long serialVersionUID = 1L;
public EventObject(Object source){
super(source);
}
public void doEvent(){
System.out.println("通知一个事件源 source :"+ this.getSource());
}

}
事件源
事件源是事件对象的入口，包含监听器的注册、撤销、通知

public class EventSource {
//监听器列表，监听器的注册则加入此列表
private Vector<EventListener ListenerList = new Vector<EventListener();
//注册监听器
public void addListener(EventListener eventListener){
ListenerList.add(eventListener);
}
//撤销注册
public void removeListener(EventListener eventListener){
ListenerList.remove(eventListener);
}
//接受外部事件
public void notifyListenerEvents(EventObject event){
for(EventListener eventListener:ListenerList){
eventListener.handleEvent(event);
}
}

}

测试执行
public static void main(String[] args) {
EventSource eventSource = new EventSource();

}
控制台显示：

通知一个事件源 source :openWindows

通知一个事件源 source :openWindows

doOpen something...

到这里你应该非常清楚的了解，什么是事件监听器模式了吧。 那么哪里是回调接口，哪里是回调者，对！EventListener是一个回调接口类，handleEvent是一个回调函数接口，通过回调模型，EventSource 事件源便可回调具体监听器动作。

有了了解后，这里还可以做一些变动。 对特定的事件提供特定的关注方法和事件触发

public class EventSource {
...
public void onCloseWindows(EventListener eventListener){
System.out.println("关注关闭窗口事件");
ListenerList.add(eventListener);
}

}
public static void main(String[] args) {
EventSource windows = new EventSource();
/**
* 另一种实现方式
*/
//关注关闭事件，实现回调接口
windows.onCloseWindows(new EventListener(){

}
这种就类似于，我们的窗口程序，Button监听器了。我们还可以为单击、双击事件定制监听器。

观察者模式
什么是观察者模式
观察者模式其实原理和监听器是一样的，使用的关键在搞清楚什么是观察者、什么是被观察者。

观察者(Observer)相当于事件监器。有个微博模型比较好理解，A用户关注B用户，则A是B的观察者，B是一个被观察者，一旦B发表任何言论，A便可以获得。
被观察者(Observable)相当于事件源和事件，执行事件源通知逻辑时，将会回调observer的回调方法update。
举个例子
为了方便，同样我直接使用jdk自带的Observer。

一个观察者
public class WatcherDemo implements Observer {
@Override
public void update(Observable o, Object arg) {
if(arg.toString().equals("openWindows")){
System.out.println("已经打开窗口");
}
}
}
被观察者
Observable 是jdk自带的被观察者，具体可以自行看源码和之前的监听器事件源类似。

主要方法有

addObserver() 添加观察者，与监听器模式类似
notifyObservers() 通知所有观察者
类Watched.java的实现描述：被观察者，相当于事件监听的事件源和事件对象。又理解为订阅的对象 主要职责：注册/撤销观察者（监听器），接收主题对象（事件对象）传递给观察者（监听器），具体由感兴趣的观察者（监听器）执行

/**

}
测试执行
public static void main(String[] args) {
Watched watched = new Watched();
WatcherDemo watcherDemo = new WatcherDemo();
watched.addObserver(watcherDemo);
watched.addObserver(new Observer(){
@Override
public void update(Observable o, Object arg) {
if(arg.toString().equals("closeWindows")){
System.out.println("已经关闭窗口");
}
}
});
//触发打开窗口事件，通知观察者
watched.notifyObservers("openWindows");
//触发关闭窗口事件，通知观察者
watched.notifyObservers("closeWindows");

控制台输出：

已经打开窗口

已经关闭窗口

总结
从整个实现和调用过程来看，观察者和监听器模式基本一样。

有兴趣的你可以基于这个模型，实现一个简单微博加关注和取消的功能。 说到底，就是事件驱动模型，将调用者和被调用者通过一个链表、回调函数来解耦掉，相互独立。

“你别来找我，有了我会找你”。

整个设计模式的初衷也就是要做到低耦合，低依赖。

再延伸下，消息中间件是什么一个模型？ 将生产者+服务中心（事件源）和消费者（监听器）通过消息队列解耦掉. 消息这相当于具体的事件对象，只是存储在一个队列里（有消峰填谷的作用），服务中心回调消费者接口通过拉或取的模型响应。 想必基于这个模型，实现一个简单的消息中间件也是可以的。

还比如gava ListenableFuture，采用监听器模式就解决了future.get()一直阻塞等待返回结果的问题。

有兴趣的同学，可以再思考下观察者和责任链之间的关系， 我是这样看的。

同样会存在一个链表，被观察者会通知所有观察者，观察者自行处理，观察者之间互不影响。 而责任链，讲究的是击鼓传花，也就是每一个节点只需记录继任节点，由当前节点决定是否往下传。 常用于工作流，过滤器web filter。

系统架构设计模式

系统架构设计模式大全

目前系统架构大约有110多种设计模式，模式不是教条，模式仅仅是经验的总结，下面我为大家整理了一些系统架构设计模式，一起来看看吧：

Domain Model：定义了一个应用领域结构和工作流的精确模型，其中还包括它们的变化。

Layers：解决系统合理分层的问题。

Model-View-Controller：解决对用户界面变化的支持问题。支持某一特定用户界面的变化。

Presentation-Abstraction-Control：解决相同业务具有多种表现形式问题。

Microkernel：解决业务具有多种不同业务方法的问题。

Refelection：解决需要动态改变软件系统结构和行为的问题。

Pipes and Filters：解决算法的结构化并可以重新构建的问题。

Shared Repository：适用于网络管理和控制系统领域。

Blackboard：解决运行中智能化改进处理方法的问题。

Domain Object：表现为已经将自我完备的连贯功能和基础性责任封装成定义良好的实体，通过一个或多个”显示接口”提供功能，并隐藏内部结构和实现。

Messaging：由一系列相互连接的MessageChannel和Message Router管理着跨网络的不同服务间的消息交换。

Message Channel：解决如何把彼此协作的客户端和服务连接起来的问题。

Message Router：解决如何根据条件接受”信道”消息的问题。

Message Translator：解决如何转换消息格式的问题。

Message Endpoint：解决把数据转换为消息中间件能够理解的形式的问题。

Publisher-Subscriber：为了在应用中更好的把彼此关注的事件通知给其它领域对象。

Broker：通过一个代理管理器管理领域对象间远程互操作的各个关键方面。

Client Proxy：解决客户端应用与网络基础设施相互屏蔽的问题。

Requestor：解决应用代码被基础设施的代码污染而影响可移植性的问题。

Invoker：解决服务代码被基础设施的代码污染而影响可移植性的问题。

Client Request Handler：解决客户端应用与通信相互影响的问题，它封装了客户端在统一的接口背后进行的进程间通信的细节。

Server Request Handler：解决服务端应用与通信相互影响的问题，封装了服务器端在统一的接口背后进行的进程间通信的细节。

Reactor：解决在应用中避免使用多线程的问题。

Proactor：解决在多线程的背景下出现性能问题的缺陷。

Acceptor-Connector：把事件初始化与具体处理方法分离，从而提高可维护性。

Asynchronous Completion Token：解决异步到达的事件仍然能按一定顺序处理的问题。

Explicit Interface：解决如何正确设计接口的问题。

Extension Interface：随着时间的推移，组件的接口是会膨胀的，一个胖的接口将更脆弱。解决防止”胖”接口并分离接口。

Introspective Interface：解决公开内部信息接口的问题。

Dynamic Invocation Interface：解决同一个接口允许客户端调用多种方法的问题。

Proxy：解决在同一个接口下通过代理屏蔽某些实现的问题。

Business Delegate：由本地业务代表来完成所有网络任务，分离了应用和网络处理的业务，减少了开发难度、提高了可理解性和可维护性。

Facade：解决屏蔽子系统的变化辐射到高层应用的问题。

Combined Method：解决多种相互关联的方法不合理的分布的问题。

Iterator：解决分布式元素能够方便迭代的问题。

Enumeration Method：解决减少外部迭代方式多次对聚合中的元素进行独立访问开销的问题。

Batch Method：解决多次访问加大网络开销的问题。

Encapsulated Implementation：解决对象划分的基本原则和方法问题。

Composite：建立一种结构灵活的树状结构对象组织形式，形成“整体/部分”层级结构。

Half-Object plus Protocol：通过在分布式系统中合理布局对象，以减少不合理的网络流量和服务器压力。

Replicated Component Group：解决分布式系统容错的问题，复制的组件实现位于不同的网络节点，并组成一个组件组。

Half-Sync/Half-Async：对并发系统中的异步和同步服务处理解耦合以简化编程，但又不会过度地影响性能。

Leader/Followers：解决大批量小处理的环境下减少并发线程应用的问题。

Active Object：为了减少服务器并发线程应用。

Monitor Object：解决并发业务相互协调的问题。

Guarded Suspension：在并发性程序中，当某个线程对一个资源进行访问的时候，首先需要判断这个资源的警戒条件是否成立。

Future：并发调用的服务可能需要向客户端返回结果。

Thread-Safe Interface：避免自死锁和加锁开销。

Strategized Locking：在创建或声明时，为组件配置适当类型的锁实例。使用该锁实例来保护组件中的所有临界区。

Scoped Locking：解决复杂繁琐代码中的疏忽发生漏释放造成死锁的问题。

Thread-Specific Storage：解决频繁使用对象造成反复加锁解锁造成的性能问题。

Copied Value：解决共享的值对象必须锁定带来的性能问题。

Immutable Value：解决共享的值对象必须锁定带来的性能问题。

Observer：定义一个特定的更新接口，通过该接口，Observer获得Subject状态变更的通知。

Double Dispatch：根据运行时多个对象的类型确定方法调用的过程。

Mediator：封装集合中所有对象的聚合协作行为，从而将这些对象解耦合。

Command：为这些对象定义一个通用接口，来执行它们所代表的请求。

Memento：解决在不破坏封装性的前提下正确存储和读取分布式对象状态的问题。

Context Object：解决在松耦合系统中共享与程序执行上下文相关的通用信息的问题。

Data Transfer Object：解决细粒度调用多次访问远程对象单个属性所带来的巨大开销问题。

Message：解决网络协议只支持比特流这种最简单的数据传输形式，并不能识别服务调用和数据类型的问题。

Bridge：解决在下层稳定的业务中嵌入上次变化部分的问题。

Object Adapter：解决接口变化导致的不兼容问题。

Chain of Responsibility：解决对象结构和请求分发逻辑上的变化影响到客户端的问题。

Interceptor：解决构建一个可插拔的框架变化模型的问题。

Visitor：解决将服务的实现分散在定义对象结构的各个类中难以进行集中处理的问题。

Decorator：解决在稳定的核心功能外围添加扩展的问题。

Template Method：解决在下层稳定的业务中嵌入上次变化部分的问题。

Strategy：解决在一个或多个方法中根据不同的情况执行不同行为的问题。

Wrapper Facade：主要解决应用代码使用底层API所提供的服务但代码难以理解的问题，需要对底层API进行面向对象的封装，通过提供一个简洁的'、健壮的、可移植的、内聚的面向对象的接口，来达到封装函数和数据的目的。

Declarative Component Configuration：建立需要安装各类插件的宿主基础设施，使其能够正确管理运行时环境，可靠运用系统资源和服务的问题。

Container：解决领域对象直接处理平台环境造成它与平台紧密耦合并增加实现的复杂性的问题。

Component Configurator：解决在组件生命周期后期和升级时重新配置组件的问题。

Object Manager：解决客户端依赖对象管理增加应用内部的耦合度和复杂度的问题。

Virtual Proxy：解决从一个巨大数据库中把所有的对象全部加载进来消耗大量资源的问题。

Resource Pool：解决获取和释放资源(网络连接、线程或者内容)引入一定的性能开销问题。

Resource Cache：解决几个有限的资源用户频繁创建和释放资源带来不必要的性能开销问题。

Automated Garbage Collection：解决不能及时将不再使用的内存收回可能耗尽内存的问题。

Counting Handles：解决确保在堆上创建的共享对象能够可靠地、安全地、及时地回收的问题。

Abstract Factory：解决一批对象用统一的方法进行创建和销毁的问题。

Builder：解决对需要多步完成对象的创建时，简化创建过程的复杂性和多样性问题。

Factory Method：解决直接创建对象可能导致代码的混乱并影响调用端代码的独立性问题。

Disposal Method：解决销毁对象时可能需要多个步骤而引人过度的耦合问题。

Database Access Layer：它通过在两种之间引人一个映射层将面向对象应用设计同关系型数据库分离开。

Data Mapper：解决数据模型和持久化的表结构之间完全的解耦合的问题。

Row Data Gateway：解决更细致的数据模型和持久化的表结构之间完全解耦的问题。

Table Data Gateway：解决更细致的数据模型和持久化的表结构之间完全解耦的问题。

Active Record：解决降低应用中面向对象数据模型与数据库中表结构之间的耦合的问题。 ; 关于事件通知设计模式和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 事件通知设计模式的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于、事件通知设计模式的信息别忘了在本站进行查找喔。