We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
简介
观察者模式又称发布订阅模式,是一种最常用的设计模式之一了。讲道理,如果我们写的不是稍微底层的代码,可能不会用到它。 但是有了它会让代码更灵活,更加规整,减少冗余代码,方便分模块,分功能开发。
引入
在前端业务中,可能用的比较多的地方可能就是自定义事件了。 其实浏览器的事件也是观察者模式
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代码跟浏览器之间有了联系,互动。而本来是两个不同的东西。
在我看来,观察者模式最大的好处就是在于解耦,会让我们一锅端的代码,分功能,分模块的抽离开,更加清晰,开发成本变低,也容易维护。 比如:
var xhr = new XMLHttpRequest () xhr.open('get',url) xhr.onreadystatechange = function () { if(this.readyState !== 4) return if(this.status === 200) { divs.innerHTML = '<p>' + this.response + '</p>' // } } 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 模块?
当然封好一个 好的完整的功能模块是挺难的一件事情,但我们起码要有个开始。
订阅去添加方法,发布了事件池就执行。
MVC也是一种设计模式,这里面也都应用了观察者。 他内部也都是各种发布订阅,好像是一个观察者模型,从而实现了一个模拟的内存中的dom改变,计算出那个DOM节点应该改变。当然具体实现要做好多事情...就不...
简单实现一个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); })
实现一个可以发布订阅的类
'use strict' class EmitterEvent { constructor() { this._event = {} } on (eventName, handler) { if(this._event[eventName]) { this._event[eventName].push(handler) } else { this._event[eventName] = [handler] } } emit (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 }) } } 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)
The text was updated successfully, but these errors were encountered:
简单实现一个createstore函数 不能直接运行啊
Sorry, something went wrong.
No branches or pull requests
观察者模式
观察者模式又称发布订阅模式,是一种最常用的设计模式之一了。讲道理,如果我们写的不是稍微底层的代码,可能不会用到它。 但是有了它会让代码更灵活,更加规整,减少冗余代码,方便分模块,分功能开发。
在前端业务中,可能用的比较多的地方可能就是自定义事件了。
其实浏览器的事件也是观察者模式
这里function click 订阅了 div 的click 事件,当我们的鼠标点击操作,事件发布,对应的function就会执行。这个function click 就是一个观察者。
其实单纯的看代码实现,也可以理解。但是万物都是有联系的,这些编程模式设计之初也是来源于生活经验吧,所以,具象的理解也是很重要的体验。
我们举一个结婚办酒席的例子。比如你的一个好朋友要结婚了,'结婚'这件事情不是天天发生,一辈子就那么一... 两次(maybe more),所以我们的'去参加他的婚礼'肯定不是天天发生,只是在特定的时候。我肯定不能天天去问他,'今天你结婚吗,我来参加酒席啊'。一次两次还行,天天问,sb啊。假如是一个找不到对象的单身汪,被你天天这么问,还不得杀了你。。
那这里就需要有一个事件发布了,也就是'通知你'。
我作为一个观察者,去订阅他'结婚' 的这个事件,就是我们是好朋友,他的婚礼我肯定去,我们已经说好了。那么我就是观察者,'我去参加婚礼'就是对应而来的动作。当我订阅了'结婚' 这个事件,我就不需要天天去问他了,我该干嘛干嘛,该去泡妞,约饭,看电影,约... 就干嘛。
当他发布'结婚' 这个事件,通知到我了,我就在特定的时候,去do'参加婚礼酒席'这个行为function ...
其实在代码中是需要一个类似于中间服务的,管理发布订阅的中间者。
比如浏览器中的事件处理程序,他提供了订阅的接口,然后接收'事件' 信号 发布给你。让js代码跟浏览器之间有了联系,互动。而本来是两个不同的东西。
在我看来,观察者模式最大的好处就是在于解耦,会让我们一锅端的代码,分功能,分模块的抽离开,更加清晰,开发成本变低,也容易维护。
比如:
其实应该是请求跟 展示渲染分开的。
直接在状态码200那里放个callback,也能做到。但是,如果我有两个甚至渲染函数,处理不同的东西,我每次还要改成不同的函数吗。 这个相同请求的过程是不是还要写一遍。
用观察者的话
好处就在于我的getData这个功能,方法就只负责请求数据,然后他会暴露一个接口,供我去添加方法。这样我的getData 就相对来说是比较完整的功能模块,就算我有再多的情况,我的getData 里面的代码是不会改动的了。
有时候我们经常为了实现业务,添加一个新的功能,而去更改我们之前写好的代码,导致我们本来的功能模块被改的面目全非。
而且会有好多的重复代码。
过程? or 模块?
当然封好一个 好的完整的功能模块是挺难的一件事情,但我们起码要有个开始。
订阅去添加方法,发布了事件池就执行。
MVC也是一种设计模式,这里面也都应用了观察者。
他内部也都是各种发布订阅,好像是一个观察者模型,从而实现了一个模拟的内存中的dom改变,计算出那个DOM节点应该改变。当然具体实现要做好多事情...就不...
The text was updated successfully, but these errors were encountered: