消失的魔术:隐藏在js引用和原型链背后的超级能力

广告位招租
扫码页面底部二维码联系

js这门语言有很多诟病,然而很多被无视的点,构成了js最为美妙的语言特性。这篇文章将带你走进魔术般的引用型数据类型和原型链背后,寻找那些被遗忘的超能力。并且,基于这些超能力,我们将实现功能极其复杂,但可以达到极为绝妙的架构设计。

引用型数据类型

称法有很多,但是在我这里,我统一称这种借鉴于java的数据结构为引用型数据类型。除去几种基本数据类型,其他所有类型都是引用型数据类型。所谓引用型数据类型,是指变量保持内存地址指针,当该指针对应的具体内容发生变化时,指向同一指针的所有变量同时发生变化。

这是一个极其复杂的设计,这里的“复杂”既包含原理上的,也包含情感上的。一台机器的内存是有限的,虽然独立的栈存储数据更有利于快速读取,但是会很快消耗完内存。而堆存储由于没有特定结构,而且js还是弱类型语言,这让读取数据又变的很慢。两难之间取舍,最后引用型数据类型成为js这门语言最原始的力量,支撑着所有程序的发展。

这就是js的“原力”,引用型数据类型决定了js的基因,很多语言特性成为那样,很大程度是因为基因决定。

举个例子,我们不能在遍历一个数组的时候,随意删除数组的某个元素:

let arr = [1, 2, 3, 4]
for (let i = 0, len = arr.length; i < len; i ++) {
  let item = arr[i]
  if (item === 2) {
    arr.splice(i, 1)
  }
  console.log(i, item)
}

在遍历过程中,我们删掉了一个元素,导致数组的长度变短,而实际循环并没有被调整,因此,我们必须写一行代码进行调整:

let arr = [1, 2, 3, 4]
for (let i = 0, len = arr.length; i < len; i ++) {
  let item = arr[i]
  if (item === 2) {
    arr.splice(i, 1)
    len = arr.length
  }
  console.log(i, item)
}

这样的操作我们司空见惯。

内存引用带来了很多副作用,因此当我们使用redux时,必须遵循它那一整套reducer的规则,如果直接修改一个对象,会导致数据虽变但值仍相等的情况:

let a = { test: 1 }
let b = a
b.test = 2
// a === b => true

这在react的组件撰写中非常危险,它使得shouldComponentUpdate等钩子不能被正常触发。

看上去这是一个大坑,大而特大的坑。但是,如果我们换一个角度,我们在什么情况下需要这样的力量?

let a = {
  data: {},
  say() {
    alert(this.data.msg)
  },
}
let b = {
  get data() {
    return a.data
  },
  say() {
    alert('my msg:' + this.data.msg)
  },
}

上面这段代码,我们的期望是,a和b共用同一个data,虽然它们在自己的行为上不同,但是它们的行为基于相同的data数据来实现,虽然上面这样写没有什么错,但是,我们为何不直接写成:

let data = {}
let a = {
  data,
  say() {
    alert(this.data.msg)
  },
}
let b = {
  data,
  say() {
    alert('my msg:' + this.data.msg)
  },
}

这样的语义不是更明确吗?我们这里非常明确的表述,a和b使用相同的data,当data改变时,同时影响它们的行为。

这样的例子你完全看不出它的威力,原因在于data太过简单。倘若,data是一个跨模块的庞大数据体系,它贯穿于你的整个应用,用户在pageA对data进行了修改,希望这个修改被带到pageB,如果通过函数来逐层传递,那估计得写N个函数吧。然而,实际上,我们只需要一个引用数据,不需要任何额外的内存开销。

原型链继承

再见识了上面的data的有趣之处后,我们再来看js的原型链继承。在js里面,各种花哨的操作实在是太多太多了,比如通过new关键字创建一个实例,比如通过extends继承一个类,比如令人抓狂的this……这些风骚的操作背后,原型链继承起到了黑色幽默的决定作用。

我相信你玩儿过docker,我不讲docker,我讲原型链。

一个优秀的原型链保证一个数据体系拥有最小单位。让我们来看下一个例子:

var obj1 = {
  a: 1,
  b: 2,
}
var obj2 = Object.assign({}, a, { b: 3 })

这段代码的目的是,创建一个obj2,使它跟obj1有大致相仿的结构,但是也有自己的特殊性。然而,仔细观察,我们会发现,obj2是对obj1的浅复制。它在表层拥有完全独立的存储空间,如果我们按照这样的方法复制一万个obj,我们会发现,内存被吃的很快。而原型链继承就像一个带着白手套的魔术师,用更为简洁的语言去描述相同结构的数据。

var obj1 = {
  a: 1,
  b: 2,
}
var obj2 = Object.create(obj1)
obj2.b = 3

虽然代码的行数增加了,然而内在的机理却在发生变化。obj2保持了最小的内存消化,但同时拥有了和obj1相似的数据结构。更为重要的是,你是否还记得前面我们谈到data被共用的场景。我们让千万个obj共用data作为一个结构模型,但使用最少量但内存消耗:

var data = {
  a: 1,
  b: 2,
}
var obj1 = Object.create(data)
Object.assign(obj1, {
  a: 3,
})
var obj2 = Object.create(data)
Object.assign(obj2, {
  b: 4,
})

当我修改data时,所有的obj都在调整,但是它们又不会丢失自己的特殊性。

原型链继承,就像是js世界的图腾,所有的js文化都在围绕着它发展壮大。这似乎有点危言耸听,但如果你认为angular是一个不错的框架的话,一定还记得angular中关于作用域的一些列描述。父级作用域在子作用域中仍然有效,但子作用域优先级更高。它背后的原理,就是利用原型链的继承来实现。

核级应用:数据快照vs数据版本控制

前面讲了那么多,有没有更感性的方式,让我们可以对这些无关痛痒的话题更加在意呢?当然有的,我们需要自己手撸一个东西,让这些零零碎碎的兴奋可以落地成核,炸开一个新宇宙。

我们知道,在使用redux时,我们可以做到一个功能,就是恢复数据,或者将连续的状态动态设置,形成界面的连续变化,终而形成肉眼可观的影像。我们的认知告诉我们,这个原理很简单,redux管理的是状态,应用一个状态对应一个界面,把每一个状态的变化保存起来,就可以得到连续的状态,也就可以得到连续的界面变化。

可是啊,如此庞大的状态,每一个变动可能就是一个微小的粒子,保存起来?也许还是太年轻。

我已经提到过docker了,不知道你还对它有没有兴趣。每一个容器基于一个镜像,镜像层层叠叠,就像是人类文明一样,后人站在前人的肩膀上。底层的镜像可以被不同的上层镜像使用,这样,就减少了同样的内容在docker中重复出现的情况。不同的应用都基于Ubuntu,只要一个Ubuntu镜像就行了,apache、php,对于一个应用的不同环境,这些底层镜像大家都相同了,但却可以跑出千万多姿的应用出来。

同样的道理,状态的改变,只是在原有状态的基础上做一点小小的定制而已,有必要把整个状态都保存起来吗?不需要,只需要保存变化过的那一点点就可以了,其他的所有,我们从上一个状态继承即可。这是最最最适合魔术师原型链发挥魔力的地方了。

母状态 -> 状态b -> 状态c -> 当前状态

在这个应用场景里,被保存过的状态从来不会被修改,它们安静的沉睡。你可以让当前的界面,犹如游标卡尺般,在这个链条上来回游动,像那些被玩儿坏的鬼畜剪辑般,游刃有余。

你可能还是git的忠实粉丝,喜欢merge功能喜欢到爆炸。在这样的原型链模型里面,你也可以轻松做到数据的版本管理:

母状态
|
状态a
|
状态b
|    \
|    状态c
|       \
状态d     |
|       /
|    状态e
|    /
状态f
|
当前状态

这样的结构,基于redux可以实现吗?或许还差那么一些,然而,基于原型链却是轻轻松松。任何一个状态,都可以由两部分组成,一部分是来自对上一个状态的继承,另一部分是来自自己独特的特殊数据。而相对而言,这些特殊数据的量总是小的。

你可能有个疑问,上面将“状态e”merge到“状态f”的过程怎么去实现呢?有两种方式:

var f = Object.create(d)
Object.assgin(f, e)

这种方式把d这条线当作master,接收来自e这条分支的pull request。

var f = new Proxy({}, {
  get: (target, prop) => {
    return target[prop] || e[prop] || d[prop]
  },
})
Object.defineProperties(f, {
  $$master: { value: d },
  $$branck: { value: e },
})

这种方式则绕一些,通过创建代理来保证同时保持了两个状态的同时继承,同时定义了两个隐式的属性来保存继承的来源,方便后期查找。这种方法比方法1更好的地方在于,方法1把状态e merge到f之后,和e就没有关系了,merge的过程,要求把e这条分支的所有改动都找出来,然后一并赋值给f,这样其实面临了前面说的保存了一些其实不用保存的数据。而方法2则很好的解决这个问题,它不需要把数据从整个e这条分支检索出来,仍然保留了原型链继承的模式。

小结

也许,你对js的爱憎分明,你渴望它更加完美,但是非常遗憾的是,每一门语言都不可能完美,否则世界上只需要一门语言,然而正式因为语言的多样性,这个世界才更加有趣。对js原始冲动的琢磨,或许就是一个兴趣的开始,你不需要纠结于语言的语法和憋足的数据类型,你领略了它原力中的super power之后,就可以享受这一场魔术盛宴了。

最后的小广告,刚刚完成了objext这个包的开发,它很好的利用了原型链的特点,实现了复杂但接口又很简单的功能,欢迎品尝 https://github.com/tangshuang/objext

2018-09-27 3279

为价值买单,打赏一杯咖啡

本文价值32.79RMB
已有1条评论
  1. 小鱼儿 2019-02-24 22:18

    var obj1 = {
      a: 1,
      b: 2,
    }
    var obj2 = Object.assign({}, a, { b: 3 })

    这句应该笔误写错了吧…