摘要:观察者模式简介观察者模式又称发布订阅模式,是一种最常用的设计模式之一了。其实浏览器的事件也是观察者模式这里订阅了的事件,当我们的鼠标点击操作,事件发布,对应的就会执行。包括在内的,只要是支持事件响应的核心模块都是的子类。
观察者模式
简介
观察者模式又称发布订阅模式,是一种最常用的设计模式之一了。讲道理,如果我们写的不是稍微底层的代码,可能不会用到它。 但是有了它会让代码更灵活,更加规整,减少冗余代码,方便分模块,分功能开发。
引入
在前端业务中,可能用的比较多的地方可能就是自定义事件了。
其实浏览器的事件也是观察者模式
div.onclick = function click() { console.log("click") }
这里function click 订阅了 div 的click 事件,当我们的鼠标点击操作,事件发布,对应的function就会执行。这个function click 就是一个观察者。
具象化理解
其实单纯的看代码实现,也可以理解。但是万物都是有联系的,这些编程模式设计之初也是来源于生活经验吧,所以,具象的理解也是很重要的体验。
我们举一个结婚办酒席的例子。比如你的一个好朋友要结婚了,"结婚"这件事情不是天天发生,一辈子就那么一... 两次(maybe more),所以我们的"去参加他的婚礼"肯定不是天天发生,只是在特定的时候。我肯定不能天天去问他,"今天你结婚吗,我来参加酒席啊"。一次两次还行,天天问,sb啊。假如是一个找不到对象的单身汪,被你天天这么问,还不得杀了你。。
那这里就需要有一个事件发布了,也就是"通知你"。
我作为一个观察者,去订阅他"结婚" 的这个事件,就是我们是好朋友,他的婚礼我肯定去,我们已经说好了。那么我就是观察者,"我去参加婚礼"就是对应而来的动作。当我订阅了"结婚" 这个事件,我就不需要天天去问他了,我该干嘛干嘛,该去泡妞,约饭,看电影,约... 就干嘛。
当他发布"结婚" 这个事件,通知到我了,我就在特定的时候,去do"参加婚礼酒席"这个行为function ...
//模拟代码 //我订阅了"marry" 事件 wo.on("marry",function(){ //去参加婚礼酒席 }) //然后他发布。比如浏览器的点击 // 对应的我的 function就会执行
解耦/模块/功能
其实在代码中是需要一个类似于中间服务的,管理发布订阅的中间者。
比如浏览器中的事件处理程序,他提供了订阅的接口,然后接收"事件" 信号 发布给你。让js代码跟浏览器之间有了联系,互动。而本来是两个不同的东西。
在我看来,观察者模式最大的好处就是在于解耦,会让我们一锅端的代码,分功能,分模块的抽离开,更加清晰,开发成本变低,也容易维护。
比如:
我们项目里的view 展示层跟model(数据处理)逻辑层,最开始写页面,ajax,字符串拼接,请求回一个接口拼一下,然后给dom。可能我们一个js文件,一个function里面又请求了接口,又去负责 view 的展示。
var xhr = new XMLHttpRequest () xhr.open("get",url) xhr.onreadystatechange = function () { if(this.readyState !== 4) return if(this.status === 200) { divs.innerHTML = "" + this.response + "
" // } } xhr.responseType = "json" xhr.send(null)
其实应该是请求跟 展示渲染分开的。
//请求 function getData () { var xhr = new XMLHttpRequest () xhr.open("get",url) xhr.onreadystatechange = function () { if(this.readyState !== 4) return if(this.status === 200) { this.emit("渲染") // 发布 } } xhr.responseType = "json" xhr.send(null) } //渲染 function view () {} xhr.on("渲染",view)
直接在状态码200那里放个callback,也能做到。但是,如果我有两个甚至渲染函数,处理不同的东西,我每次还要改成不同的函数吗。 这个相同请求的过程是不是还要写一遍。
用观察者的话
function view1 () {} function view2 () {} function view3 () {} function view4 () {} if(我要渲染view1) { xhr.on("渲染",view1) //订阅 xhr.on("渲染",view2) }else{ xhr.on("渲染",view3) xhr.on("渲染",view4) }
好处就在于我的getData这个功能,方法就只负责请求数据,然后他会暴露一个接口,供我去添加方法。这样我的getData 就相对来说是比较完整的功能模块,就算我有再多的情况,我的getData 里面的代码是不会改动的了。
有时候我们经常为了实现业务,添加一个新的功能,而去更改我们之前写好的代码,导致我们本来的功能模块被改的面目全非。
而且会有好多的重复代码。
过程? or 模块?
当然封好一个 好的完整的功能模块是挺难的一件事情,但我们起码要有个开始。
订阅去添加方法,发布了事件池就执行。
MV* 类框架
MVC也是一种设计模式,这里面也都应用了观察者。
他内部也都是各种发布订阅,好像是一个观察者模型,从而实现了一个模拟的内存中的dom改变,计算出那个DOM节点应该改变。当然具体实现要做好多事情...就不...
redux
简单实现一个createstore函数
//这是一个工厂函数,可以创建store const createStore = (reducer) => { let state; // 定义存储的state let listeners = []; // getState的作用很简单就是返回当前是state const getState = ()=> state; //定义一个派发函数 //当在外界调用此函数的时候,会修改状态 const dispatch = (action)=>{ //调用reducer函数修改状态,返回一新的状态并赋值给这个局部状态变量 state = reducer(state,action); //依次调用监听函数,通知所有的监听函数 listeners.forEach(listener => listener()); } //订阅此状态的函数,当状态发生变化的时候记得调用此监听函数 const subscribe = function(listener){ //先把此监听 加到数组中 listeners.push(listener); //返回一个函数,当调用它的时候将此监听函数从监听数组移除 return function(){ listeners = listeners.filter(l => l != listener); } } //默认调用一次dispatch给state赋一个初始值 dispatch(); return { getState, dispatch, subscribe } } let store = createStore(reducer); //把数据渲染到界面上 const render = () => { document.body.innerText = store.getState(); } // 订阅状态变化事件,当状态变化时用监听函数 store.subscribe(render); render(); var INCREASE_ACTION = {type: "INCREMENT"}; document.addEventListener("click", function (e) { //触发一个Action store.dispatch(INCREASE_ACTION); })
在node 中的作用 大多数时候我们不会直接使用 EventEmitter,而是在对象中继承它。包括fs、net、 http 在内的,只要是支持事件响应的核心模块都是 EventEmitter 的子类。
实现一个可以发布订阅的类
"use strict" class EmitterEvent { constructor() { //构造器。实例上创建一个事件池 this._event = {} } //on 订阅 on (eventName, handler) { // 根据eventName,事件池有对应的事件数组, 就push添加,没有就新建一个。 // 严谨一点应该判断handler的类型,是不是function if(this._event[eventName]) { this._event[eventName].push(handler) } else { this._event[eventName] = [handler] } } emit (eventName) { // 根据eventName找到对应数组 var events = this._event[eventName]; // 取一下传进来的参数,方便给执行的函数 var otherArgs = Array.prototype.slice.call(arguments,1) var that = this if(events) { events.forEach((event) => { event.apply(that, otherArgs) }) } } // 解除订阅 off (eventName, handler) { var events = this._event[eventName] if(events) { this._event[eventName] = events.filter((event) => { return event !== handler }) } } // 订阅以后,emit 发布执行一次后自动解除订阅 once (eventName, handler) { var that = this function func () { var args = Array.prototype.slice.call(arguments,0) handler.apply(that, args) this.off(eventName,func) } this.on(eventName, func) } } var event = new EmitterEvent() function a (something) { console.log(something,"aa-aa") } function b (something) { console.log(something) } event.once("dosomething",a) event.emit("dosomething", "chifan") //event.emit("dosomething") // event.on("dosomething",a) // event.on("dosomething",b) // event.emit("dosomething","chifan") // event.off("dosomething",a) // setTimeout(() => { // event.emit("dosomething","hejiu") // },2000)
当我们需要用的时候,只需要继承一下这个EmitterEvent类。要操作的实例就可以用on,emit方法,也就是可以用发布订阅。比如XHR,组件...
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/86639.html
摘要:概念观察者模式被广泛地应用于客户端编程中。所有的浏览器事件,等都是使用观察者模式的例子。在观察者模式中,一个对象订阅另一个对象的指定活动并得到通知,而不是调用另一个对象的方法。此外,观察者模式还可用于实现数据绑定。 概念 观察者模式被广泛地应用于JavaScript客户端编程中。所有的浏览器事件(mouseover,keypress等)都是使用观察者模式的例子。这种模式的另一个名字叫自...
摘要:解决命名空间问题暂不管,删除订阅问题这个用处不大目前我们先着手解决这个问题对应的消息么有被人订阅没有传入具体的回调函数表示取消对应的所有订阅反向遍历删除订阅回调函数这个对象,能够解决大部分事件模拟的问题。 订阅发布模式如果按数学翻译其实就是.一对多的映射关系.怎么解释呢? 就是一个开关,同时并联几个灯泡(在不同房间),触发的时候,几个灯泡都会得到指令,然后执行发光的行为。 订阅发布模式...
摘要:发布者注册发布订阅者自动打印消息消息观察者模式与发布订阅模式类似。在此种模式中,一个目标物件在它本身的状态改变时主动发出通知,观察者收到通知从而使他们的状态自动发生变化。 做为非科班出身的前端er,每次听到设计模式都感觉很高大上,总感觉这些东西是造火箭原子弹用的,距离我们这些造螺丝钉很遥远。但是最近在做一个聊天消息的业务时,发现貌似用上发布订阅模式业务就很清晰了。创建一个消息类当作发布...
摘要:最近被人问到设计模式,观察者模式和发布订阅模式二者有什么区别。观察者模式观察者模式,目标和观察者是基类,目标提供维护观察者的一系列方法,观察者提供更新接口。 最近被人问到设计模式,观察者(Observer)模式和发布(Publish)/订阅(Subscribe)模式二者有什么区别。其实这两种模式还是有些许差异的,本质上的区别是调度的方式不同。 观察者模式 观察者模式,目标和观察者是基类...
阅读 2780·2021-10-14 09:50
阅读 1194·2021-10-08 10:21
阅读 3625·2021-10-08 10:16
阅读 3005·2021-09-27 14:02
阅读 3114·2021-09-23 11:21
阅读 2049·2021-09-07 10:17
阅读 373·2019-08-30 14:00
阅读 2069·2019-08-29 17:26