观察者模式又叫发布订阅模式(Publish/Subscribe),它定义了一种一对多的关系,让多个观察者对象同时监听某一个主题对象,这个主题对象的状态发生变化时就会通知所有的观察者对象,使得它们能够自动更新自己。讲道理,如果我们写的不是稍微底层的代码,可能不会用到它。 但是有了它会让代码更灵活,更加规整,减少冗余代码,方便分模块,分功能开发。
引入
在前端业务中,可能用的比较多的地方可能就是自定义事件了。
其实浏览器的事件也是观察者模式
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代码跟浏览器之间有了联系,互动。而本来是两个不同的东西。
在我看来,观察者模式最大的好处就是在于解耦,会让我们一锅端的代码,分功能,分模块的抽离开,更加清晰,开发成本变低,也容易维护。
比如:
1、我们项目里的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 = '<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 模块?
当然封好一个 好的完整的功能模块是挺难的一件事情,但我们起码要有个开始。
订阅去添加方法,发布了事件池就执行。
2、MV* 类框架
MVC也是一种设计模式,这里面也都应用了观察者。他内部也都是各种发布订阅,好像是一个观察者模型,从而实现了一个模拟的内存中的dom改变,计算出那个DOM节点应该改变。当然具体实现要做好多事情…就不…
3、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);
})
4、在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,组件…
单例模式是我们开发中一个非常典型的设计模式,js单例模式要保证全局只生成唯一实例,提供一个单一的访问入口,单例的对象不同于静态类,我们可以延迟单例对象的初始化,通常这种情况发生在我们需要等待加载创建单例的依赖。
工厂模式下的对象我们不能识别它的类型,由于typeof返回的都是object类型,不知道它是那个对象的实例。另外每次造人时都要创建一个独立的person的对象,会造成代码臃肿的情况。
建造者模式:是将一个复杂的对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。工厂类模式提供的是创建单个类的模式,而建造者模式则是将各种产品集中起来进行管理,用来创建复合对象
主要涉及知识点: HTML与XHTML,HTML与XHTML的区别,DOCTYPE与DTD的概念,DTD的分类以及DOCTYPE的声明方式,标准模式(Standard Mode)和兼容模式(Quircks Mode),标准模式(Standard Mode)和兼容模式(Quircks Mode)的区别
JavaScript中常见的四种设计模式:工厂模式、单例模式、沙箱模式、发布者订阅模式
javascript 策略模式的定义是:定义一系列的算法,把它们一个个封装起来,并且使它们可以相互替换。 策略模式利用组合,委托等技术和思想,有效的避免很多if条件语句,策略模式提供了开放-封闭原则,使代码更容易理解和扩展, 策略模式中的代码可以复用。
熟悉 Vue 的都知道 方法methods、计算属性computed、观察者watcher 在 Vue 中有着非常重要的作用,有些时候我们实现一个功能的时候可以使用它们中任何一个都是可以的
我觉得聊一下我爱用的 JavaScript 设计模式应该很有意思。我是一步一步才定下来的,经过一段时间从各种来源吸收和适应直到达到一个能提供我所需的灵活性的模式。让我给你看看概览,然后再来看它是怎么形成的
在围绕设计模式的话题中,工厂这个词频繁出现,从 简单工厂 模式到 工厂方法 模式,再到 抽象工厂 模式。工厂名称含义是制造产品的工业场所,应用在面向对象中,顺理成章地成为了比较典型的创建型模式
简单工厂模式中,可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。 比如你去专门卖鼠标的地方你可以买各种各样的鼠标
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!