Decorator 是 ES7 的一个新语法，正如其“装饰器”的叫法所表达的，他可以对一些对象进行装饰包装然后返回一个被包装过的对象，可以装饰的对象包括：类，属性，方法等。Decorator 的写法与 Java 里的注解（Annotation）非常类似，但是一定不要把 JS 中的装饰器叫做是“注解”，因为这两者的原理和实现的功能还是有所区别的，在 Java 中，注解主要是对某个对象进行标注，然后在运行时或者编译时，可以通过例如反射这样的机制拿到被标注的对象，对其进行一些逻辑包装。而 Decorator 的原理和作用则更为简单，就是包装对象，然后返回一个新的对象描述（descriptor），其作用也非常单一简单，基本上就是获取包装对象的宿主、键值几个有限的信息。
关于 Decorator 的详细介绍参见文章：zhuanlan.zhihu.com/FrontendMag…
简单来说，JS 的装饰器可以用来“装饰”三种类型的对象：类的属性/方法、访问器、类本身，简单看几个例子吧。
针对属性/方法的装饰器
// decorator 外部可以包装一个函数，函数可以带参数
function Decorator(type){
/**
* 这里是真正的 decorator
* @target 装饰的属性所述的类的原型，注意，不是实例后的类。如果装饰的是 Car 的某个属性，这个 target 的值就是 Car.prototype
* @name 装饰的属性的 key
* @descriptor 装饰的对象的描述对象
*/
return function (target, name, descriptor){
// 以此可以获取实例化的时候此属性的默认值
let v = descriptor.initializer && descriptor.initializer.call(this);
// 返回一个新的描述对象，或者直接修改 descriptor 也可以
return {
enumerable: true,
configurable: true,
get: function() {
return v;
},
set: function(c) {
v = c;
}
}
}
}复制代码
注意这里的 target 对应的是被装饰的属性所属类的原型，如果是装饰一个 A 类的属性，并且 A 类是继承自 B 类的，这时候你打印 target，获取到的是 A.prototype，它的结构是这样的，这里一定要注意：
[image:A944761A-E0FA-4C04-BD90-BE179C46B641-35651-00001223828250C5/187FCC2A-8CC4-46C4-B8A3-A7FD5E0376F6.png]
如果需要操作 target，可能需要搞清楚这个问题。
针对 访问操作符的装饰
与属性方法类似，就不详述了。
class Person {
@nonenumerable
get kidCount() { return this.children.length; }
}
function nonenumerable(target, name, descriptor) {
descriptor.enumerable = false;
return descriptor;
}复制代码
针对类的装饰
// 例如 mobx 中 @observer 的用法
/**
* 包装 react 组件
* @param target
*/
function observer(target) {
target.prototype.componentWillMount = function() {
targetCWM && targetCWM.call(this);
ReactMixin.componentWillMount.call(this);
};
}复制代码
其中的 target 就是类本身（而不是其 prototype）
真实场景应用
今天，我们要介绍的主要是，如何将 Decorator 这个特性应用于数据定义层，实现一些类似于类型检查、字段映射等功能。
关于数据定义层（Model），其实就是应用内出现的各种实体数据的定义，也就是 MVVM 中的 M 层，注意，和 VM 层做好区分，Model 本身不提供数据的管理和流通，只负责定义某个实体本身的属性和方法，例如页面里有一辆车的模块，我们就定义一个 CarModel，它用来描述车辆的颜色、价格、品牌等信息。
关于为什么要在前端应用内定义明确的 Model，这个我之前在知乎上也早有论述，核心几点：
- 提高可维护性。将数据源头的实体做一个固定而准确的描述，这个对于串联理解整个应用非常重要，特别是在重构或者接手别人的代码的时候，你需要准确的知道一个页面（或者是一个模块）它会包含哪些数据，这些数据分别有哪些字段，这样更便于理解整个应用的数据逻辑。
- 提高确定性。当你要给你的界面增加几个车辆字段的时候，你不清楚之前是否已经定义过这些字段，服务端是否会返回这些字段，可能要请求一下（并且要有权限取到所有字段）才能知道，但是如果有 model 的明确定义，有什么字段就一目了然了。
- 提高开发效率。在这一层统一做一些数据映射和类型检查等工作，这也是今天要讲的重点。
以我们团队 RN 开发框架中 Model 部分的实现为例，我们至少提供了三个基础的基于 Decorator 的功能：类型检查，单位转换，字段映射。接下来我会先简单介绍下这几个功能是做什么的，随后介绍如何实现这些 Decorator。
先来看看最终调用时候的代码
class CarModel extends BaseModel {
/**
* 价格
* @type {number}
*/
@observable
@Check(CheckType.Number)
@Unit(UnitType.PRICE_UNIT_WY)
price = 0;
/**
* 卖家名
* @type {string}
*/
@observable
@Check(CheckType.String)
@ServerName('seller_name')
sellerName = '';
}复制代码
可以看到我们有三个自定义的 decorator ：
@Unit, // 单位转换装饰器
@Check, // 类型检查装饰器，
@ServerName // 数据字段映射装饰器，当前后端定义的字段名不一致的时候用复制代码
@Unit 是一个比较特殊的装饰器，它的作用是在前后端之间自动转换单位，也就是前端和后端交换某些带单位的数据的时候，会把根据各端的注解和装饰器，把真实值转换成带单位的值传给另一端，然后另一端会在框架层自动转成它定义的单位，以此解决前后端单位不一致，交换数据时混乱导致的问题。
被 @Unit 装饰过的属性，读写的时候都是按照前端的单位读写，然后再转换成 JSON 的时候就会特殊处理成类似 12.3_$wy 这样的格式，表示这个数的单位是万元。
@Check 更为容易理解，就是用来检查字段类型，或者检查字段格式，或者一些自定义检查，例如正则表达式等。
@ServerName 则用来做映射，例如前后端对同一个界面元素的命名不同，这时候不需要完全按照服务端的命名来决定，可以在前端用另外一个属性名，然后将其装饰成服务端的字段名。
