观察者模式

给出一个例子： 　　小球砸在地面，达成一个成就“蛋疼”。砸在地面，听起来是需要物理引擎参与吧，但我们总不能在物理引擎计算各种力学公式的时候强行插入一个unlockEggPain()方法吧，观察者模式就出来有话说了。 def undateEntity(entity): entity.accelerate(GRAVITY) entity.update() if entity.IsOnSurface(): notify(entity, EVENT_ON_FACE) 　　这里，我们实现了某个东西砸在地上了，感兴趣的人自行关注。 　　成就系统就可以注册自己进去，收到信息后检查是否和自己相关，有则进行运算，否则抛弃。这样成就系统和物理系统没进行耦合，任何一方的存亡也没另一边的关系。 如何实现： 　　定义观察者 　 class ObSever: def onNotify(entity, event): pass 　　继承obsever即可成为观察者，就是那么简单。 class Achievents(Obsever): def onNotify(entity, event): if event == EVENT_ON_FACE: self.Unlock(ACHIEVENT_EGG_PAIN) elif xxx: pass 此外，还得定义被观察的对象，称为客体 class Subject: def

package com.thread.ch4; import java.util.ArrayList; import java.util.List; /** * 观察者模式 */ public class Subject { //被观察的对象 private List<Observer> observerList = new ArrayList<>(); private int state; public int getState() { return state; } public void setState(int state) { if (state == this.state) { return; } this.state = state; notifyAllObserver(); } public void attach(Observer observer) { observerList.add(observer); } public void notifyAllObserver() { observerList.stream().forEach(Observer::update); } } package com.thread.ch4; public abstract class Observer { protected Subject subject; public

简言之 ：观察者模式(Observer),当一个对象状态发生改变时，依赖它的对象全部会收到通知，并自动更新。 具体描述 ：一个对象通过添加一个方法（该方法允许另一个对象-观察者，注册自己）使本身变得可观察。当可观察的对象更改时，它会将消息发送到已注册的观察者。这些观察者使用该信息执行的操作与可观察的对象无关。结果是对象可以相互对话，而不必了解原因。观察者模式是一种时间系统，意味着这一模式允许某个类观察另一个类的状态。当被观察的类状态发生改变的时候，观察类可以收到通知并且做出相应的动作，观察者模式避免组件之间的紧密耦合。 观察者模式中的角色 ： Subject(抽象主题角色)：主题角色将所有观察者对象的引用保存在一个集合中，每个主题可以有任意多个观察者。抽向主题提供了增加和删除观察者对象的接口。 Observer（抽象观察者角色）：为所有的具体观察者定义一个接口，在观察的主题发生改变时更新自己。 ConcreteSubject（具体主题角色）：存储相关状态到具体观察者对象，当具体主题的内部状态改变时，给所有登记过的观察者发出通知，具体主题角色通常用一个具体子类实现。 ConcreteObserver（具体观察者角色）：存储一个具体主题对象，存储相关状态，实现抽象观察者角色所要求的更新接口，以使得其自身状态和主题的状态保持一致。 推荐阅读代码： PHP设计模式之观察者模式

一个NSNotificationCenter对象(通知中心)提供了在程序中广播消息的机制，它实质上就是一个通知分发表。这个分发表负责维护为各个通知注册的观察者，并在通知到达时，去查找相应的观察者，将通知转发给他们进行处理。 本文主要了整理了一下NSNotificationCenter的使用及需要注意的一些问题，并提出了一些未解决的问题，希望能在此得到解答。 获取通知中心 每个程序都会有一个默认的通知中心。为此，NSNotificationCenter提供了一个类方法来获取这个通知中心： + (NSNotificationCenter *)defaultCenter 获取了这个默认的通知中心对象后，我们就可以使用它来处理通知相关的操作了，包括注册观察者，移除观察者、发送通知等。 通常如果不是出于必要，我们一般都使用这个默认的通知中心，而不自己创建维护一个通知中心。 添加观察者 如果想让对象监听某个通知，则需要在通知中心中将这个对象注册为通知的观察者。早先，NSNotificationCenter提供了以下方法来添加观察者： - (void)addObserver:(id)notificationObserver selector:(SEL)notificationSelector name:(NSString *)notificationName object:(id

一：身边的观察者模式 传统的报纸和杂志的订阅就是一种观察者模式： 报社的业务就是出版报纸 向某家报社订阅报纸，只要他们有新报纸出版，就会给你送来。只要你是他们的订户，你就会一直收到新报纸来。 当你不想再看报纸的时候，取消订阅，他们就不会再送新报纸来。 只要报社还在运营，就会有人（或单位）向他们订阅报纸或取消订阅报纸。 　 二：什么是观察者模式 由报社和订报人的关系可以看出：出版者+订阅者 = 观察者模式 观察者模式 ：定义了对象之间的一对多依赖，当一个对象改变状态时，它所有的依赖者都会收到通知并自动更新。 定义观察者模式 《interface》Subject:主题接口，对象使用此接口注册为观察者，或者把自己从观察者中删除。 ConcreteSubject:具体主题，实现了主题接口，除了注册和撤销方法之外，具体主题还实现了notifyObservers()，此方法用于在状态改变时更新所有当前观察者。 《interface》Observer:观察者接口，这个接口只有update()一个方法，当主题状态改变时它被调用。 Observer:具体观察者，必须注册具体主题，以便接受更新。 当两个对象之间松耦合，他们依然可以交互，但是不太清楚彼此的细节。观察者模式提供了一种对象涉及，让主题和观察者之间松耦合 三：下面我拿lol游戏中的实景来写段代码，体现游戏中的观察者模式（为了更好的理解

本笔记摘抄自： https://www.cnblogs.com/PatrickLiu/p/7928521.html ，记录一下学习过程以备后续查用。 一、引言 今天我们要讲行为型设计模式的第四个模式--观察者模式，先从名字上来看。观察者模式可以理解为既然有“观察者”，那肯定就有“被观察者”了。“观察者” 监视着“被观察者”，如果“被观察者”有所行动，“观察者”就会做出相应的动作来回应。听起来是不是有点像“谍战”的味道？比如“谍影重重”那类优秀的影片。 观察者模式在现实生活中，实例其实是很多的，比如：八九十年代我们订阅的报纸，我们会定期收到报纸，因为我们订阅了。银行可以给储户发手机短信， 也是观察者模式很好的使用的例子，因为我们订阅了银行的短信业务，当我们账户余额发生变化就会收到通知。还有很多，我就不一一列举了，发挥大家的 想象吧。好了，接下来，就让我们看看该模式具体是怎么实现的吧。 二、观察者模式介绍 观察者模式：英文名称--Observer Pattern；分类--行为型。 2.1、动机（Motivate） 在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系”--一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。 如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系

文章目录 设计模式——观察者设计模式结合事件发布 几个要素 代码实现 画图总结 设计模式——观察者设计模式结合事件发布 几个要素 要素一： 被观察者持有观察者的引用，有多个观察者，所以得用list存储 要素二： 支持动态注册观察者，注销观察者 要素三： 可以发布事件并且通知所有观察者 要素四： 观察者只会观察自己感兴趣的事件 代码实现 观察者相关代码 public interface EventListener { boolean support ( Event event ) ; //感兴趣的事件 void update ( ) ; //感兴趣后执行逻辑 } public class L1 implements EventListener { @Override public boolean support ( Event event ) { if ( event instanceof StartEvent ) return true ; return false ; } @Override public void update ( ) { System . out . println ( "l1" ) ; } } public class L2 implements EventListener { @Override public boolean support ( Event

发布订阅和观察者模式 今天的话题是 javascript 中常被提及的「发布订阅模式和观察者模式」，提到这，我不由得想起了一次面试。记得在去年的一次求职面试过程中，面试官问我，“你在项目中是怎么处理非父子组件之间的通信的？”。我答道，“有用到 vuex ，有的场景也会用 EventEmitter2 ”。面试官继续问，“那你能手写代码，实现一个简单的 EventEmitter 吗？” 手写EventEmitter 我犹豫了一会儿，想到使用 EventEmitter2 时，主要是用 emit 发事件，用 on 监听事件，还有 off 销毁事件监听者， removeAllListeners 销毁指定事件的所有监听者，还有 once 之类的方法。考虑到时间关系，我想着就先实现发事件，监听事件，移除监听者这几个功能。当时可能有点紧张，不过有惊无险，在面试官给了一点提示后，顺利地写出来了！现在把这部分代码也记下来。 class EventEmitter { constructor() { // 维护事件及监听者 this.listeners = {} } /** * 注册事件监听者 * @param {String} type 事件类型 * @param {Function} cb 回调函数 */ on(type, cb) { if (!this.listeners[type]) { this

模式的定义与特点 观察者（Observer）模式的定义：指多个对象间存在一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。这种模式有时又称作发布-订阅模式、模型-视图模式，它是对象行为型模式。 观察者模式是一种对象行为型模式，其主要优点如下。 降低了目标与观察者之间的耦合关系，两者之间是抽象耦合关系。 目标与观察者之间建立了一套触发机制。 它的主要缺点如下。 目标与观察者之间的依赖关系并没有完全解除，而且有可能出现循环引用。 当观察者对象很多时，通知的发布会花费很多时间，影响程序的效率。 原文链接 http://www.javaxmw.com/info?intId=30 public class ObserverTest { public static void main(String[] args) { SubjectM subject = new ConcreateSubject(); Observer observer1 = new ConcreteObserver1(); Observer observer2 = new ConcreteObserver2(); subject.add(observer1); subject.add(observer2); subject.notifyObserver(); } } interface

设计模式； 一个程序员对设计模式的理解: “不懂”为什么要把 很简单的东西搞得那么复杂 。后来随着软件开发经验的增加才开始明白我所看到的“复杂”恰恰就是设计模式的精髓所在， 我所理解的 “简单”就是一把钥匙开一把锁的模式，目的仅仅是着眼于解决现在的问题，而设计模式的“复杂”就在于它是要构造一个“万能钥匙”，目的是提出一种对所有锁的开锁方案。 在真正理解设计模式之前我一直在编写“简单”的代码. 这个 “简单”不是功能的简单，而是设计的简单。 简单的设计意味着缺少灵活性，代码很钢硬，只在这个项目里有用，拿到其它的项目中就是垃圾，我将其称之为 “一次性代码”。 -->要使代码可被反复使用,请用'设计模式'对你的代码进行设计. 很多我所认识的程序员在接触到设计模式之后，都有一种相见恨晚的感觉，有人形容学习了设计模式之后感觉自己好像已经脱胎换骨，达到了新的境界， 还有人甚至把是否了解设计模式作为程序员划分水平的标准。 我们也不能陷入模式的陷阱，为了使用模式而去套模式，那样会陷入形式主义。我们在使用模式的时候，一定要注意模式的意图（intent），而不 要过多的去关注模式的实现细节，因为这些实现细节在特定情况下，可能会发生一些改变。不要顽固地认为设计模式一书中的类图或实现代码就代表了模式本身。 设计原则：( 重要 ) 1. 逻辑代码独立到单独的方法中，注重封装性--易读，易复用。