TypeScript 中的枚举是什么许多编程语言（例如 C，C# 和 Java）都具有 enum 数据类型，而 JavaScript 没有。但是 TypeScript 可以，TypeScript 具有基于数字和基于字符串的枚举。TypeScript 枚举允许开发人员定义一组命名常量。使用它们可以更轻松地记录意图或创建一组不同的案例。枚举的语法如下：enum States { Apple, Orange， Banana， Watermelon } // 使用 var fruit = States.Watermelon;在 TypeScript 中使用枚举需要注意什么首先枚举中的值是常量，即枚举是类型安全的，在重新分配值时会返回编译错误。其次枚举应该是有限的，有助于用户创建一个自定义的常量系统。枚举在被编译后是一个对象：在 JavaScript 中创建内存有效的自定义常量，使用灵活易于表达记录意图方便作为判断用例。enum requestStatus { success = 200 error = 400 } let requestStatus; (function (requestStatus) { requestStatus[requestStatus["success"] = 200] = "success" requestStatus[requestStatus["error"] = 400] = "error" })(requestStatus || (requestStatus = {})); // requestStatus: // { '200': 'success', '400': 'error', error: 400, success: 200 }常见枚举的类型数值枚举 和 字符串枚举 是我们在 TypeScript 中最常用的枚举类型，下面我将用例子向你们介绍它们的特点以及如何使用它们。数字枚举数字枚举以字符串存储数字值 。让我们使用 enum 关键字定义它们。下面我将用存储一组不同类型汽车的示例展示 TypeScript 中的数字枚举：enum CarType { Honda, Toyota, Subaru, Hyundai }枚举值 CarType 有四个值：本田，丰田，斯巴鲁和现代。枚举值从 0 开始，并且每个成员的值递增 1 ，如下所示：Honda = 0Toyota = 1Subaru = 2Hyundai = 3如果需要你可以自己初始化第一个数值，如下所示：enum CarType { Honda = 1, Toyota, Subaru, Hyundai }在上面的示例中，Honda 使用数值 1 初始化了第一个成员。剩余的数字将加一。你可能会想，如果我更改最后一个值，之前的值会根据最后定义的数值递减吗？让我们来试试：enum CarType { Honda, Toyota, Subaru, Hyundai = 100 }遗憾的是这是行不通的，当前例子的数值是：enum CarType { Honda, // 1 Toyota, // 2 Subaru, // 3 Hyundai // 100 }注意：不必为枚举成员分配顺序值。你可以为其分配任何所需的值字符串枚举字符串枚举类似于数字枚举，但是它们的枚举值是使用字符串值而不是数字值初始化的。 字符串枚举比数字枚举具有更好的可读性 ，从而更容易调试程序。以下示例使用与数值枚举示例相同的信息，但以字符串枚举表示：enum CarType { Honda = "HONDA", Toyota = "TOYOTA", Subaru = "SUBARU", Hyundai = "HYUNDAI" } // 访问字符串枚举 CarType.Toyota; //return TOYOTA注意：字符串枚举值需要单独初始化。枚举反向映射枚举可以使用其相对应的枚举成员值检索 num 值。使用反向映射，可以访问成员值和成员值的名称，请看下面的例子：enum CarType { Honda = 1, Toyota, Subaru, Hyundai } CarType.Subaru; //return 3 CarType.["Subaru"]; //return 3 CarType[3]; //return SubaruCarType[3] 由于反向映射，返回其成员名称“ Subaru”。让我们看另一个例子：enum CarType { Honda = 1, Toyota, Subaru, Hyundai } console.log(CarType)在浏览器的控制台中将看到以下输出：{ '1'：'Honda'， '2'：'Toyota'， '3'：'Subaru'， '4'：'Hyundai'， Honda：1， Toyota：2， Subaru：3， Hyundai：4 }枚举的每个值在内部存储的枚举对象中出现两次。计算枚举枚举成员的值可以是常量值或计算值。请看下面的示例：enum CarType { Honda = 1, Toyota = getCarTypeCode('toyota'), Subaru = Toyota * 3, Hyundai = 10 } function getCarTypeCode(carName: string): number { if (carName === 'toyota') { return 5; } } CarType.Toyota; // returns 5 CarType.Subaru; // returns 15如果枚举既包含计算成员又包含常量成员，则未初始化的枚举成员将首先出现，也可能在其他带有数字常量的初始化成员之后。下一个示例将显示错误：enum CarType { Toyota = getCarTypeCode('toyota'), Honda, // Error: Enum member must have initializer Subaru, Hyundai = Toyota * 3, }你可以这样声明上述枚举：enum CarType { Honda, Hyundai, Toyota = getCarTypeCode('toyota'), Subaru = Toyota * 3如果你想开发小程序或者了解更多小程序的内容，可以通过专业开发公司，来帮助你实现开发需求：厦门在乎科技-专注厦门小程序开发公司、APP开发、网站开发、H5小游戏开发

开发者学堂课程【LINUX 企业常用服务：MySql数据库服务配置】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/802MySql数据库服务配置 一MySql服务介绍 Mysql是开源的关系型数据库管理系统,原开发者为瑞典的MySQL AB公司后来被orcale公司收购,由于MySql数据库的性能高成本低,已经成为最流行的关系型数据库被广泛的使用在internet的中小网站上,随着Mysql的不断成熟,也开始逐渐用于更大规模的网站与应用比如谷歌,维基百科等并且支持Linux,windows,Mac OS solaris AIX等多种操作系统和处理拥有上万条的大数据同时提供了多种编程语言的API例如C,java C#,C++,php,Rudy,python等支持多线程多用户还有jdbc OOBC等数据库连接提供管理检查数据库管理工具.二MySql服务的配置

原创 JSCON 淘系技术  6月9日历史渊源和设计标准我们知道，在 ES6 的规范当中，ES6 支持元编程，核心是因为提供了对 Proxy 和 Reflect 对象的支持。简单来说这个 API 的作用就是可以实现对变量操作的函数化，也就是反射。对于其他语言的程序员来讲，比如说 Java 或者 C#，元编程和 Metadata 是相对熟悉的，而对于 JSer 目前接触的并非很多，所以相对会陌生一些。关于 ES6 元编程，我之前写过一篇教程《ES6 元编程（Proxy & Reflect & Symbol）》可以看看，这里就不展开了然而 ES6 的 Reflect 规范里面还缺失一个规范，那就是 Reflect Metadata。这会造成什么样的情境呢[2]？由于 JS/TS 现有的 装饰器更多的是存在于对函数或者属性进行一些操作，比如修改他们的值，代理变量，自动绑定 this 等等功能。但是却无法实现通过反射来获取究竟有哪些装饰器添加到这个类/方法上... 这就限制了 JS 中元编程的能力。此时 Relfect Metadata 就派上用场了，可以通过装饰器来给类添加一些自定义的信息。然后通过反射将这些信息提取出来（当然你也可以通过反射来添加这些信息）。综合一下， JS 中对 Reflect Metadata 的诉求，简单概括就是：其他 C#、Java、Pythone 语言已经有的高级功能，我 JS 也应该要有（诸如C＃ 和 Java 之类的语言支持将元数据添加到类型的属性或注释，以及用于读取元数据的反射API，而目前 JS 缺少这种能力）许多用例（组合/依赖注入，运行时类型断言，反射/镜像，测试）都希望能够以一致的方式向类中添加其他元数据。为了使各种工具和库能够推理出元数据，需要一种标准一致的方法；元数据不仅可以用在对象上，也可以通过相关捕获器用在 Proxy 上对开发人员来说，定义新的元数据生成装饰器应该简洁易用；什么是metadata（元数据）首先解释一下 metadata 这个概念，并非所有人都了解这个名词的含义 —— 其实每个人平时都经常接触过，只是不知道它叫 metadata 而已。简言之，有数据库开发经验的同学，元数据概念其实是跟数据库的字段名（field）一致 —— 在传统的数据库中就天然包含元数据的概念。比如一个人的简历上写着 “姓名” 是 “张三”，那么表示成 JS 对象就是：{ "name": "张三" }那么我们设计数据库的时候，一般将 name 设计成存储列名（field），这样不同简历的人就能按照 name 进行检索了，因此我们称 “name” 就是一个元数据 —— 没了，就是这么简单。所以但凡你在 JS 中遇到元数据编程，你就假想成自己在设计数据库就行了。讲到这里，我就继续啰嗦两句，方便扩散思维。HTML的 <head> 标签里可以定义 <meta> 标签。<meta> 元素可提供有关页面的元信息（meta-information），比如针对搜索引擎和更新频度的描述和关键词。"keywords" 是一个经常被用到的，提高网站 SEO 绕不开的一个设置项（某些搜索引擎在遇到这些关键字时，会用这些关键字对文档进行分类）：<meta name="keywords" content="HTML,JavaScript,CSS,前端">在我们了解完 metadata 的概念后，我们可以开始学习如何使用它了。如何开始metadata编程?TypeScript 已经完整的实现了装饰器，后续的讲解默认都以 TS 环境（虽然 Babel 也可以，但是需要各种配置，比较繁琐）。Reflect Metadata 是 15 年提出的一个提案，现在我们想要使用这个功能，可以借助仓库 reflect-metadata，先 npm 安装这个库：npm i reflect-metadata --saveTypeScript 支持为带有 装饰器 的声明 生成元数据。你需要在命令行或 tsconfig.json里启用emitDecoratorMetadata编译器选项：{ "compilerOptions": { "target": "ES5", "experimentalDecorators": true, "emitDecoratorMetadata": true } }当启用后，只要reflect-metadata库被引入了，设计阶段添加的类型信息可以在运行时使用。基础用法严格地说，元数据（metadata）和 装饰器(Decorator) 是 EcmaScript 中两个独立的部分。 然而，如果你想实现像是 反射这样的能力，你总是同时需要它们。比如下方这个例子：// 要引入这个库 import "reflect-metadata"; @Reflect.metadata('name', 'Person') class Person { @Reflect.metadata('words', 'hello world') public speak(): string { return 'hello world' } } Reflect.getMetadata('name', Person) // 'Person' Reflect.getMetadata('words', new Person(), 'speak') // 'hello world' // 这里为什么要用 new A()，用 A 不行么？后文会讲到是不是很简单？对照这个例子，我们再引出 Metadata 的四个概念：Metadata Key {Any}（后文简写 k）。元数据的 Key，对于一个对象来说，它可以有很多元数据，每一个元数据都对应有一个 Key。一个很简单的例子就是说，你可以在一个对象上面设置一个叫做 'name' 的 Key 用来设置他的名字，用一个 'created time' 的 Key 来表示他创建的时间。这个 Key 可以是任意类型。在后面会讲到内部本质就是一个 Map 对象。Metadata Value {Any} （后文简写 v）。元数据的类型，任意类型都行。Target {Object} （后文简写 o）。表示要在这个对象上面添加元数据Property {String|Symbol} （后文简写 p）。用于设置在哪个属性上添加元数据。大家可能会想，这个是干什么用的，不是可以在对象上面添加元数据了么？其实不仅仅可以在对象上面添加元数据，甚至还可以在对象的属性上面添加元数据。其实大家可以这样理解，当你给一个对象定义元数据的时候，相当于你是默认指定了 undefined 作为 Property。 了解了这 4 个概念，我们阅读对应的 API 就会比较容易。API设计最为全面的 API 可以查阅标准文档： https://rbuckton.github.io/reflect-metadata/API 的设计也是非常清晰明了，metadata 毕竟也属于 “数据”，那么对应的 API 就是跟数据库的 CURD 增删改查的操作相对应的。先罗列一下完整的 API 声明，然后我们在挨个拆分讲解：namespace Reflect { // 用于装饰器 metadata(k, v): (target, property?) => void // 在对象上面定义元数据 defineMetadata(k, v, o, p?): void // 是否存在元数据 hasMetadata(k, o, p?): boolean hasOwnMetadata(k, o, p?): boolean // 获取元数据 getMetadata(k, o, p?): any getOwnMetadata(k, o, p?): any // 获取所有元数据的 Key getMetadataKeys(o, p?): any[] getOwnMetadataKeys(o, p?): any[] // 删除元数据 deleteMetadata(k, o, p?): boolean }▐  创建元数据（Reflect.metadata/Reflect.defineMetadata）两种方式创建，其最本质都是调用源码中 OrdinaryDefineOwnMetadata 方法，所以结果是一样的，只是使用方式不一样。一种是通过装饰器声明方式创建，推荐的方式，也是很主流的一种方式：// 装饰类 @Reflect.metadata(key, value) class Example { } // 装饰静态属性 class Example { @Reflect.metadata(key, value) static staticProperty; } // 装饰实例属性 class Example { @Reflect.metadata(key, value) property; } // 装饰静态方法 class Example { @Reflect.metadata(key, value) static staticMethod() { } } // 装饰实例方法 class Example { @Reflect.metadata(key, value) method() { } }另一种就是 “事后”（类创建完后）再给目标对象创建元数据：class Example { // property declarations are not part of ES6, though they are valid in TypeScript: // static staticProperty; // property; constructor(p) { } static staticMethod(p) { } method(p) { } } // 给 类本身 加元数据 Reflect.defineMetadata("custom:annotation", options, Example); // 给 类的静态属性 新增元数据 Reflect.defineMetadata("custom:annotation", options, Example, "staticProperty"); // 给 类的实例属性 新增元数据，注意是加在 prototype 上 Reflect.defineMetadata("custom:annotation", options, Example.prototype, "property"); // 给 类的静态方法 新增元数据 Reflect.defineMetadata("custom:annotation", options, Example, "staticMethod"); // 给 类的实例方法 新增元数据，注意是加在 prototype 上 Reflect.defineMetadata("custom:annotation", options, Example.prototype, "method");这两种方式之间的联系就是，装饰器方法 Reflect.metadata 其实内部就是用 Reflect.defineMetadata 实现的：function metadata(metadataKey: any, metadataValue: any): Decorator { return (target, key?) => Reflect.defineMetadata("custom:annotation", options, target, key); }▐  查询元数据这里的 “查询” 是加引号的，因为元数据的查询的功能很简单，只要该元数据即可，不需获取要写 SQL 那么复杂。由于涉及到原型链，所以每个 API 都存在一对，用以区分是否包含原型链的操作。获取元数据（getMetadata/getOwnMetadata）这里涉及到两个相关的 API，getMetadata/getOwnMetadata 两个方法，它们之间的区别前者会包含原型链查找，后者不会查找原型链。（类似于 Object.hasProperty 和 Object.hasOwnProperty 这两个方法的区别）举例如下：class A { @Reflect.metadata('name', 'hello') hello() {} } const t1 = new A() const t2 = new A() // 给 t2.hello 新增元数据内容 otherName -> world // 此时会新增到 t2.prototype（原型链） 上（注意不是 A.prototype 上） Reflect.defineMetadata('otherName', 'world', t2, 'hello'); // 首先，t1/t2 自己能获取原本的原型链 name 对应的元数据 Reflect.getMetadata('name', t1, 'hello') // 'hello' Reflect.getMetadata('name', t2, 'hello') // 'hello' // t1 自身上没定义 otherName 的元数据 Reflect.getMetadata('otherName', t1, 'hello') // undefined // t2 自身定义了 otherName 的元数据 Reflect.getMetadata('otherName', t2, 'hello') // 'world' // t2 自身上只有 otherName 这个元数据，没有 name 元数据（该元数据来自父级） Reflect.getOwnMetadata('name', t2, 'hello') // undefined Reflect.getOwnMetadata('otherName', t2, 'hello') // 'world'判断是否存在元数据（hasMetadata/hasOwnMetadata）同样的涉及到两个相关的 API，hasMetadata/hasOwnMetadata 两个方法，它们两者调用方式一样，唯一的区别是前者会包含原型链查找，后者不会查找原型链。而且入参含义跟getMetadata/getOwnMetadata 两个方法是一样的：class Example { // property declarations are not part of ES6, though they are valid in TypeScript: // static staticProperty; // property; constructor(p) { } static staticMethod(p) { } method(p) { } } // 类本身 上是否存在元数据 result = Reflect.hasMetadata("custom:annotation", options, Example); // 类的静态属性 上是否存在元数据 result = Reflect.hasMetadata("custom:annotation", options, Example, "staticProperty"); // 类的实例属性 上是否存在元数据，注意是在 prototype 上 result = Reflect.hasMetadata("custom:annotation", options, Example.prototype, "property"); // 类的静态方法 上是否存在元数据 result = Reflect.hasMetadata("custom:annotation", options, Example, "staticMethod"); // 类的实例方法 上是否存在元数据，注意是在 prototype 上 result = Reflect.hasMetadata("custom:annotation", options, Example.prototype, "method");获取 metaKeys（getMetadataKeys/getOwnMetadataKeys）同样的涉及到两个相关的 API，getMetadataKeys/getOwnMetadataKeys 两个方法。class Example { // property declarations are not part of ES6, though they are valid in TypeScript: // static staticProperty; // property; constructor(p) { } static staticMethod(p) { } method(p) { } } // 获取 类本身 的元数据 keys result = Reflect.getMetadataKeys(Example); // 获取 类的静态属性 的元数据 keys result = Reflect.getMetadataKeys(Example, "staticProperty"); // 获取 类的实例属性 的元数据 keys，注意是从 prototype 上获取 result = Reflect.getMetadataKeys(Example.prototype, "property"); // 获取 类的静态方法 的元数据 keys result = Reflect.getMetadataKeys(Example, "staticMethod"); // 获取 类的实例方法 的元数据 keys，注意是从 prototype 上获取 result = Reflect.getMetadataKeys(Example.prototype, "method");▐  删除元数据用于删除元数据的 API 是 deleteMetadata，如果对象上有该元数据, 则会删除成功返回 true, 否则返回 false。因为比较简单, 就直接上例子了:const type = 'type' @Reflect.metadata(type, 'class') class DeleteMetadata { @Reflect.metadata(type, 'static') static staticMethod() {} } const res1 = Reflect.deleteMetadata(type, DeleteMetadata) const res2 = Reflect.deleteMetadata(type, DeleteMetadata, 'staticMethod') const res3 = Reflect.deleteMetadata(type, DeleteMetadata) console.log(res1, res2, res3) // true true false（注意并没有 deleteOwnMetadata 这样的 API）TS福利：design：类型元数据这里需要提及一点的是，在 TS 中的 reflect-metadata 是经过扩展[5]的（也就是说功能更加强劲），我们看个例子：import "reflect-metadata"; class Foo { @Reflect.metadata("hello", "world") public say(a: string): string { return 'foo'; } }我们查看其转换出来的 JS 代码，你会发现处理我们自己的元数据 "hello"->"world" 之外，还会额外给我们添加 "design:type"、"design:paramtypes" 和 "design:returntype" 这 3 个类型相关的元数据。之所以会有，这是因为我们在 TS 中开启了 emitDecoratorMetadata（https://www.typescriptlang.org/tsconfig#emitDecoratorMetadata）编译选项，这样 TS 在编译的时候会将类型元数据自动添加上去。这也是 TS 强类型编程带来的额外好处 —— 换言之如果你用 ES6 编程，需要自己加这 3 个元数据。（当然，如果你关闭 emitDecoratorMetadata选项，也就没有这 3 个类型元数据了）design:xxx 的内容分别表示什么意思呢[4]?design:type 表示被装饰的对象是什么类型, 比如是字符串? 数字? 还是函数等design:paramtypes 表示被装饰对象的参数类型, 是一个表示类型的数组, 如果不是函数, 则没有该 keydesign:returntype 表示被装饰对象的返回值属性, 比如字符串,数字或函数等我们看个例子[4]：@Reflect.metadata('type', 'class') class A { constructor(public name: string, public age: number) { } @Reflect.metadata(undefined, undefined) method():boolean { return true } } const t1 = Reflect.getMetadata('design:paramtypes', A) const t2 = Reflect.getMetadata('design:returntype', A.prototype, 'method') const t3 = Reflect.getMetadata('design:type', A.prototype, 'method') console.log(...t1, t2, t3)打印输出为:但是要注意：没有装饰的 target 是 get 不到这些 metadata 的必须手动指定类型, 否则无法进行推断。比如 method 方法如果不指定返回值为 boolean, 那么 t2 将会是 undefined应用的顺序为 type -> paramtypes -> returntype按理说本文到此就结束了，如果想看 reflect-metadata 源码是如何的，可以继续阅读下去。进阶：reflect-metadata源码设计解读我还是比较推荐阅读源码的，何况 reflect-metadata 的源码（地址：https://github.com/rbuckton/reflect-metadata/blob/master/Reflect.ts）不算多，咋一看有 1.8k 多行，可真正看下来核心源码没几行的。首先刨除声明 + 注释就已经去了一大半的行数了。接着就是 polyfill 部分，按照一般的套路，很多 polyfill 库会让你提供一些前置的 polyfill ，但是 reflect-metadata 这个库竟然内部自己实现了很多的 polyfill 和算法 —— 比如 Map, Set, WeakMap, UUID。如果把这部分的 polyfill 源码也刨除掉，真正实现 reflect-metadata 的逻辑就几百行代码，是不是很惊喜意外？核心源码比较简单，这里就不陈述，这里主要陈述一下 reflect-metadata 中有关源码的设计理念，权当抛砖引玉。▐  数据结构[3]应用该库之后，每个对象都有 [[Metadata]]属性，该属性是一个 Map 对象，该对象内 key 值内容对应目标元素上的 property 名（或为 undefined），那对应的值也是一个 Map 对象（该对象的 key/value 内容就是元数据的 key/value）—— 这其实就阐明了 metadata 存储的数据结构，是理解所有 API 行为的基础。这里所言“存在于对象下面的 [[Metadata]] 属性下面”，一开始我认为是新建一个 Symbol('Metadata')，然而实际上并非如此，取而代之的是一个 WeakMap 中。主要是利用 WeakMap 不增加引用计数的特点，将对象作为 Key，元数据集合作为 Value，存到 WeakMap 中去，类似这样的结构：WeakMap<any, Map<any, Map<any, any>>>从调用的角度来思考就会发现这样的很合理：weakMap.get(o).get(p).get(k)先根据对象（object）获取，然后在根据属性（property），最后根据元数据（metadata）的 Key 获取最终要的数据。这里再展开说明一下具体存储的位置：当在类 C 本身上使用 metadata 的时候，元数据会存储在 C.[[Metadata]] 属性中，其对应的 property 值是 undefined定义在类 C 静态成员上的元数据，那么元数据会存储在C.[[Metadata]] 属性中，以该属性（property）名作为 key 定义在类 C 实例成员上的元数据，那么元数据会存储在C.prototype.[[Metadata]] 属性中，以该属性（property）名作为 key从数据结构上我们可以看出其设计理念也很清晰：给对象添加额外的信息，但是不影响对象的结构 —— 这一点很重要，当你给对象添加了一个原信息的时候，对象是不会有任何的变化的，不会多 property，也不会有的 property 被修改了。但却可以衍生出很多其他的用途（比如可以让装饰器拥有真正装饰对象而不改变对象的能力。让对象拥有更多语义上的功能）▐  内置方法API在阅读标准的时候，你会发现，其实每个对象会拥有一系列的内部方法 [[DefineOwnMetadata]], [[GetOwnMetadata]], [[HasOwnMetadata]] 方法，设计用意是：这些内部方法可以被 Proxy 重载，支持额外的 trap这些内部方法将调用一组抽象操作来定义和读取元数据双方括号代表这是 JavaScript 引擎内部使用的属性/方法，一般是可以 console 到控制台中可以帮助 debug（点一下[[FunctionLocation]]就能跳到定义，点一下[[Scopes]]就能查看闭包，点击 [[proto]] 查看原型链等等），但是正常 JavaScript 代码（就是我们平时写代码的时候）是取不到这些属性的；比如我们在控制台中输出 Proxy 对象的时候，经常可以看到这样的代码：参考文章[1]. 元数据（MetaData）http://www.ruanyifeng.com/blog/2007/03/metadata.html，阮一峰的文章，通俗易懂[2]. 什么是元数据？为何需要元数据？https://www.zhihu.com/question/20679872，知乎文章[3]. JavaScript Reflect Metadata 详解 https://www.jianshu.com/p/653bce04db0b, XGHeaven。推荐，较为全面的一篇文章，文中很多内容都借鉴自此文。[4]. reflect-metadata的研究https://juejin.cn/post/6844904152812748807#heading-9，蒋礼锐. 源码层面的解读，推荐[5]. Reflection in Typescript https://radzserg.medium.com/reflection-in-typescript-af68a1536ea1, Sergey Radzishevskii. 

来源：淘系技术公众号作者：淘系技术近期，在 ECMA 标准化组织的 TC39 技术委员会上，阿里巴巴前端标准化小组与淘系技术提出的 JavaScript 标准提案《Error Cause》进入了 Stage 3，将开始在 JavaScript 引擎中开始实现，并在浏览器、Node.js 实验性实施，是中国首个推进到 EcmaScript 的语言，将成为官方标准的自主技术提案。ECMA/T39 是什么？ECMA 是一个负责信息技术和通信系统的国际标准组织，全称欧洲标准化信息和通信系统协会。其中 ECMA/TC39 是技术委员会第 39 号技术委员会，主要负责 JavaScript 相关标准的制定，包括：ECMA-262，即 JavaScript 的标准 ECMAScript 定义；ECMA-402，即 ECMAScript 的国际化标准 API（ECMAScript Intl API）定义；ECMA-404，即 JSON 定义；T39 的成员主要包括：谷歌、微软、苹果、阿里巴巴、360、华为、腾讯等；Error Cause 提案简介提案链接：https://github.com/tc39/proposal-error-cause这个提案为 Error Constructor 新增了一个可选的参数 options，其中可以设置 cause 并且接受任意 JavaScript 值（JavaScript 可以 throw 任意值，如 undefined 或者字符串），将这个值赋值到新创建的 error.cause 上。错误原因的特性在许多其他语言中都有类似的设计，如 C# Exception Cause，Java Exception Cause，Python raise exception from cause。同样的，在庞大的 JavaScript 生态中也已经有非常广泛的使用，如 verror 每周有上千万的下载量，@netflix/nerror 每周有数十万的下载量。因为 Error Cause 以前没有标准化的参数定义及官方实现，所以容易丢失 error 的属性或需要写比较多的代码自定义等，并且开发者工具也难以依赖于非语言特性的自定义方案。本提案将 cause 写入了语言定义，能有效记录错误原因的值，可让开发者工具、应用监控如 Alinode 都能基于 cause 属性值获取错误逻辑链条，从而提升前端开发效率，降低重复开发成本。作为阿里巴巴在加入 Ecma 标准化组织 TC39 技术委员会后的第一个落地的提案，这只是淘系技术在技术标准化上非常小的一步。未来我们之所以进行这些提案，也是因为随着云原生技术在前端工程方面的大规模应用，语言的观测性能力格外重要。语言的观测能力直接影响到语言运行时的性能与成本。我们维护的 Node.js 发行版 Alinode 会在云原生时代的继续追求成本和性能的平衡。未来，我们也会结合阿里巴巴在步向云原生的技术业务场景，继续增加投入诸如异步上下文等关于观测性的核心语言特性提案，寻找 JavaScript 中长期以来困扰开发者的异步编程上下文追踪难题的解决方案，帮助基于云原生的业务建设更加精准、高机器效率、高工程效率的观测能力。众所周知，Serverless 能够有效的优化成本，而“弹性”则是这一过程必不可少的手段。为了更好的实现弹性，启动速度是很关键的一环。Alinode Cloud Serverless Worker 按照 Web API 标准提供 JavaScript 运行环境，具有亚毫米级启动，业务应用 100ms 内启动并响应的特点，未来还将可以通过 Snapshot 快速水平（甚至跨服务器）扩展。淘系技术非常注重标准化的参与和建设，我们也会继续从内部的技术场景中挖掘编程语言的拓展场景，探索商业技术、开发者与编程语言之间的深层次编程模型。同时，我们在前端其它核心领域的标准化也有所布局，比如 W3C 相关提案也在逐步推进中：滚动回收容器 Sliver：https://github.com/w3c/chinese-ig/issues/239解决 Web 标准下滚动视图的复用回收问题，客户端开发中有 RecyclerView/UITableView 来实现滚动回收的布局容器，提案的 Display Sliver 定义了容器的布局方式以及当子元素滚动出 viewport 后的回收特性。常用手势事件：https://github.com/w3c/chinese-ig/issues/240解决 Web 标准下集成常用的手势能力，客户端开发中有各种原生自带的如 Pan、Long Press 、Drag 等在 touch 之上封装的常用的基础手势能力，这使开发者可以更方便地直接使用这些手势能力，去快速开发一些交互更复杂的页面。提案期望在事件层做进一步的扩展，开发者可以直接在节点上绑定监听相关的手势事件，并在行为触发时派发相关事件。作者|淘系技术编辑|橙子君出品|阿里巴巴新零售淘系技术

原创 于艳平(少琛) 淘系技术  3月30日值类型与值对象我们都知道，Java 语言中的类型分为两种：基本类型（primitive type）和引用类型（reference type），这不仅是语言层面的特性，也由 JVM 内在实现支持[1]。其中，基本类型指是的 8 种基本的数值类型：boolean、byte、char、int、short、long、float、double；而引用类型，指的是对程序中创建的对象的引用，可以理解为指向对象的指针或句柄。Java 号称一切皆是对象，很可惜，这并不是事实，基本类型就不是对象。那么，值类型又是什么呢？在你编写程序时，是否经常会遇到一些需要表达数值或其它类型值的场景？比如复数、向量、颜色值、坐标点、时间、日期等。这些值通常无法用基本类型来表达，一则它可能是多个属性构成，二则针对值的一些操作或逻辑我们希望跟数据封装在一起，比如向量的点乘、叉乘、取模等。但如果使用对象来表达同样也会产生很多问题：▐  相等性比较对这些对象的比较是有意义的，但是默认情况下 Java 对象比较的是地址，因此直接比较的结果通常不是我们期待的行为：▐  可变性对引用类型的赋值、方法传参等会生成多个引用，这些引用都指向同一个对象。这在一些情况下是没有问题的，但在某些场景下可能导致对象发生预期之外的变化。如：上面的 case 比较简单，只要对 Date 的特性有些了解就不会犯这样的错误。但如果对象经过多次传递，使用的位置离创建的位置很远的话，我们就未必能这么谨慎了。这种问题，Martin Flower 称之为 aliasing bug[2]。▐  性能上面两点其实都容易解决，只是每个实现需要写很多样板代码。需要比较的对象只要重写 equals() 和 hashCode 方法即可；对于可变性问题，可以将对象设计为不可变对象，在修改时返回一个深拷贝副本来供客户端操作。满足上述两种条件的对象，我们可以称之为值对象。那么，通过“对象”来实现我们对这种数据结构的诉求，是否是最好的方式呢？我们知道，Java 中的对象通常是分配在堆上，通过引用来进行操作，不过这不是必然的。JVM 有一项技术叫逃逸分析[3]，可以在运行时分析出一个方法中创建的对象是否会逃逸到方法或线程外部，如果没有逃逸，可以进而执行一些编译优化，比如栈上分配、同步消除、标量替换等。如果一个对象被分配到栈上，就意味着当方法结束后就会自动销毁，省去了 GC 的开销，这对于优化应用内存占用和 GC 停顿时间来说，无疑是个好消息；而标量替换意味着压根就不会创建对象，相关数据被替换成基本类型数据直接分配到栈上，不仅省去了对象操作相关开销，也更利于 CPU 高速缓存或寄存器进行优化。对于值对象来说，一般极少有共享的需求，假如能直接在栈上进行分配，那么将省去对象的存储、访问和 GC 的成本，对程序性能非常有利。不过进行逃逸分析也是有成本的，如果在语言层面直接支持的话，就可以进一步减少编译时分析的开销。不过，目前 Java 语言还做不到这一点。当一门编程语言为上述类型的数据结构提供内在支持时，该类型可称之为值类型。而对于满足上述诉求的实例，无论是基于值类型实现还是普通对象类型实现，我们都可以称之为值对象。不同编程语言对值类型的支持▐  Java上面已经说过，Java 语言层面原生并不支持值类型。不过，它提供了许多具有值类型特点的类，比如：8个基本类型对应的封装类、String、BigDecimal 等，这些类的共同特点之一就是不可变性，同时也都对比较操作做了实现，因此都可看作值对象。另外一个应该设计为不可变、但实际可变的类是 java.util.Date 类，也因为如此，Date 类饱受诟病。在 Java 8 中官方正式推出新的 时间/日期 API，试图取代 Date 相关接口，这些新的类全部被设计成了不可变类。对于Java 是否应该从语言层面支持值类型的讨论由来已久，比如这篇JEP提案[4]早在 2012 时就提议支持值对象；oracle 论坛上的这篇博客[5]也对如何实现值对象做了探讨。最近有两篇提案，一个提出了 Primitive Object[6]的概念，可算是值类型的一种实现；另外一篇提议基于Primitive Object统一基本类型与对象类型[7]。不过，这两个提案仍处于 Submitted 阶段（JEP 提案从提出到发布的流程有几个阶段，可以看 这里[8] Process states 一节），能否被采纳、实现乃至发布到正式版本，还是未知之数。▐  C++C++ 中没有值对象这一概念，不过在创建对象时，允许开发者选择在堆上还是在栈上创建。比如下面的示例代码，直接通过 A a; 的方式创建的对象是分配在栈上的，而通过 new A(); 的方式创建的对象分配在堆上，并且返回一个指向该对象的指针。在栈上创建的对象在函数执行结束时会自动销毁。更进一步，对 A 类型的对象进行赋值（34行）或方法传参（38行）时，会产生一次拷贝操作，生成一个新的对象，新对象的作用域分别为当前函数和被调函数，相应函数执行结束时也会被销毁。而对指针类型的对象进行赋值（43行）和方法传参（45行）时，尽管创建了新的指针对象，新的指针仍然指向相同的对象。可见 C++ 中对类类型和指针类型的使用，分别具有值类型和引用类型的一些特点。▐  C#C# 语言中是明确的提出了值类型[9]这一概念的，struct 就是一种值类型。MSDN文档中说明：“默认情况下，在分配中，通过将实参传递给方法并返回方法结果来复制变量值。” 在赋值操作时，也同样会对对象进行拷贝。如下面的代码所示，我们可以看到将 p1 赋值给 p2，p2 修改状态后，p1 中的数据仍然保持不变。另外，在 C# 中值类型是分配在栈上的，值类型与引用类型之间可以进行转化，称之为装箱和拆箱，上面的 Java Primitive Object 提案似乎也借鉴了 C# 的设计思想。▐  其它语言其它编程语言对值类型的支持不尽相同。以函数式编程为例，大多数函数式编程语言中变量都是不可变的，因此在函数式语言中定义的数据结构都可看作是值类型。DDD 中的值对象尽管 Java 并没有对值对象提供语言层面的类型支持，但这并不妨碍我们在自己的代码中创建事实上的值对象。实际上值对象[10]的定义可以并不仅限于类似向量、颜色值、坐标点这样一些使用范围。Martin Flower 认为，值对象在编程中的作用被极大的忽视了，善于值对象可以非常有效的简化你的系统代码；Vaughn Vernon 在《实现领域驱动设计》一书中甚至说，我们应该尽量使用值对象建模而不是实体对象。实际上，当提到“值对象”这个概念时，最常见的就是在 DDD（领域驱动设计）这个上下文中。Eric Evans 在《领域驱动设计 软件核心复杂性应对之道》一书中提出了实体（Enity）与值对象（Value Object）的概念。Vaughn Vernon 在《实现领域驱动设计》中做了进一步阐述。在 DDD 中，实体代表具有个性特征或需要区分不同个体的对象，它具有唯一标识和可变性。对于实体对象，我们首要考虑的并不是其属性，而是能代表其本质特征的唯一标识，无论对象属性如何变化，它都是同一个对象，它的生命周期具有连续性，甚至对对象进行持久化存储然后基于存储来重建对象，它仍然是同一个对象的延续。而值对象，它通常是一些属性的集合，是对对象的度量和描述。值对象应该是不可变的，当度量和描述改变时，可以用另外一个值对象替换。值可以跟其它值对象进行相等性比较。可以看到，在 DDD 中的值对象的定义跟我们上面的描述非常相似。《实现领域驱动设计》对于值对象的阐述非常详尽，想要进一步了解的可以阅读该书第 6 章内容。使用值对象的好处因为值对象通常设计为不可变对象，因此值对象的好处首先就是不可变对象的好处。另外在支持值类型的语言中，值对象的创建、操作、销毁会有更好的性能。▐  线程安全在 Java 编程语言中，出现线程安全问题的必要条件有两个：对象状态被多个线程共享；对象状态可变。因此解决线程安全问题的思路也主要从几个方向出发：无状态；状态不可变；不共享状态；通过同步机制来序列化对象状态的访问。而不可变对象状态是不变的，因此是线程安全的，可以放心应用到并发环境中，无需额外的同步机制在多个线程中共享。▐  避免 Alias BugAliasing bug 的概念上文已经讲过，主要是指多个对象的引用被分享到多个环境中后，在某个环境的改动会导致从另外一个环境中看到预期之外的变化。最近我们的项目中就遇到这样一个 bug，某个对象会被缓存到本地内存中，取出对象后，返回给 UI 层的某个属性值需要根据请求环境做一些判断与变更，由于未做防御性拷贝，导致变化污染了缓存对象，后面的请求出现错误的结果。而不可变对象不允许修改属性值，任何状态的变化必须通过创建副本来实现，因此可以有效的避免该类 bug。▐  简化逻辑复杂程度任何使用到值对象的地方，它的状态始终是合法的。通常不可变对象会在创建时进行自校验，因此一旦创建完成，它始终处于合法有效的状态之中，没有任何行为能使破坏它的一致性状态。可以安全的共享给其它对象、其它线程，而不用担心状态发生变化，简化了代码维护者对流程、逻辑的理解。可以作为构件简化其它对象的状态管理。当其它对象使用不可变对象作为其构件时，由于不可变对象自身状态不变，使得它在被传入和获取时不需要进行防御性拷贝，简化了对象状态的跟踪。▐  使你的设计更清晰值对象与基础类型数据相比，富含业务语义，在任何使用到它的地方，其含义一看便知。它还可以封装跟数据相关的业务逻辑，避免为了复用代码而创建 util 类，更符合面向对象的思想。▐  可比较、可以被集合类使用相信这一点不需要再说明了。值对象 Java 实践那么，如何在我们的代码中创建不可变对象呢？我们分为部分内容来讲，第一部分是指导思想，第二部分是如何进行实践。▐  值对象创建指南创建不可变对象在 《Effective Java 第三版》 第 17 条 最小化可变性一节中，将不可变类的设计归纳为五条原则：不要提供修改对象状态的方法确保这个类不能被继承把所有属性设置为 final把所有的属性设置为 private确保对任何可变组件的互斥访问第 2、3、4 点很容易理解。对第 1 点，也就是说对任何涉及状态变更的操作，都不能直接修改原始对象的状态，而是通过创建对象的副本，比如下面对复数对象的“加”操作：对于第 2 点，确保类不能被继承，除了将类设为 final，还有一种方式是将构造方法设为 private，并向外提供静态工厂方法来创建实例。而第 5 点的意思是，“如果你的类有任何引用可变对象的属性，请确保该类的客户端无法获得 对这些对象的引用”。举例而言，下面的 Period 类，尽管满足上面的 1~4 点，但由于其状态变量中包含了引用对象，引用对象通过构造方法与访问方法与外界共享，导致它的状态也会发生变化（第 7 行、第 10 行）：一个解决方案是，不使用 Date 对象，而是使用 Java 8 中提供的 LocalDate 对象，该对象是不可变的。另一种方案，在引用共享的位置对对象进行拷贝。由此可以延伸出：尽可能使用不可变对象作为构建对象的组件；必要时对构造方法参数和方法返回值进行防御性拷贝：(第 6、7、14、18 行)这里还要注意几点：进行防御性拷贝应在参数检查之前执行，以避免参数检查可拷贝期间受其它线程对参数更改的影响。必要时，对实现 serializable 接口的类进行反序列化重写 readObject 方法，以避免字节码攻击。对于这一点，简单来讲就是由于 Java 对象的反序列默认通过 readObject 方法重建对象，而不会调用我们提供的构造方法，这使得攻击者可以通过修改字节码数据，从而绕开构造方法中的参数校验的防御性拷贝。具体可以看 《Effective Java 第三版》 第 88 条 保护性的编写 readObject 方法。当构造方法参数过多时，可以借助 builder 设计模式这一点可参照《Effective Java 第三版》 第 2 条。这里不展开了。尽可能重用实例由于不变对象在修改数据时会进行拷贝，因此它的一个主要问题就是可能会创建过多的对象，这会带来性能问题。一个方案是，对可能会经常用到的对象提供公共的静态 final 常量。这一点，既可以通过公共的常量字段来实现，也可以通过静态工厂方法来实现。相等性判断需要重写 equals() 和 hashCode() 方法。至于为什么以及如何实现，相信大家都知道了，就不展开讲了。创建即合法这一点也很好理解，既然值对象是不可变的，那么创建完成之后没有任何方法可以改变的状态，因此必须在构造时进行必要的合法性校验，使创建出来的对象满足其所有的不变性条件（Invariants）。▐  如何实现手写代码有了指导思想，如何实现其实就一目了然了。只不过，要实现不可变对象，需要创建大量的样板代码，比如 equals() 和 hashCode() 方法的重写、builder 模式的创建等等。这些重复代码不仅写起来费力，而且会使类的核心业务逻辑隐藏在大量的样板代码中，降低了类的可读性。因此，最好实现方式还是借且代码生成工具。基于代码生成工具(i) lombok @value 注解lombok 库的 @value 注解可以很方便的帮我们生成一个不可变的值对象类型。如：如果我们使用 Intellij IDEA 工具，并且安装了 lombok 插件，可以在源代码处 右键 -> Refactor -> Delombok -> All lombok annotations，来查看 lombok 注解处理器处理过后生成的字节码对应的源代码大概是什么样子。这里有一点需要注意，lombok 工具对于引用类型不会帮我们做防御性拷贝，因此假如我们的构成组件包含可变对象，需要我们自己去做防御性拷贝。做法很简单，只要提供我们自己的构造方法和 get 方法，lombok 就不会再帮我们生成对应的方法。如果我们要对参数进行合法性校验，也同样需要提供自定义的构造方法，在构造方法中添加校验逻辑。(ii) lombok @Builder 注解lombok 的 @Builder 注解非常强大，可以应用在类上、构造方法上，也可以应用在静态工厂方法上。在构建时未传入的参数为该类型的默认值。同样的，如果你需要校验，可提供自定义的全参数构造方法。上面我们提到过，对值对象的实例尽可能的重用。如果我们使用静态工厂方法，就可以实现这一点：注意我们把 @Builder 注解放在了 of() 静态工厂方法上面，同时将构造方法设为 private。通过查看生成的代码，发现 builder 的 build() 方法直接调用了该工厂方法。(iii) lombok @With 注解@Value 注解会将生成的类设为不可变，如果我们需要修改对象的状态，怎么办？上面说过，修改状态需要创建拷贝。使用 @With 注解可以很方便的做到这一点。(iv) 与 mapstruct 配合使用在进行领域驱动设计时，我们经常会在不同的层或者模块之间使用不同的对象，比如持久化层使用跟数据库纪录进行映射的 DO 对象，而在领域层使用更具有业务意义的领域对象。如何在对象之间进行属性的拷贝呢？可以有很多种选择，我最常用的是 mapstruct 工具，该工具非常强大，不仅支持不同名称、不同类型字段的映射，还可以使用表达式、方法调用等。对于它我们不做过多介绍，有兴趣可以看这里[11]。在进行属性拷贝时，通常基于无参构造函数创建对象，然后设置对应属性。但是上面的类，我们在实现不可变特性时，不再提供无参构造函数。如何让 mapstruct 支持这种类呢？恭喜你，只要加了 @Builder 注解，什么都不需要做，mapstruct 已经内置提供了对 lombok @Builder 注解的支持。至于使用其它手段的属性拷贝，我暂时没有去了解，熟悉的同学可以参与讨论。(v) json 反序列化我们知道，当使用 json 反序列化工具生成自定义类型的实例时，通常也是使用该类型的默认无参构造方法。假如没有该构造方法，运行时就会抛出异常。但是，我们不希望提供该构造方法来破坏对象的不可变性。怎么办呢？这里又要祭出 lombok 的另一法宝，@Jacksonized 注解。加上这一注解后，我们的不可变对象就可以被 jackson json 库顺利的创建出来了（需要跟 @Builder 一起使用）。其实这个注解没什么复杂之处，能实现这点得益于 jackson json 库本身对 builder 模式的支持，@Jacksonized 注解只是按照 jackson json 的相关要求生成相关的 builder 类和方法而已。目前 fastjson 库似乎不支持使用 builder 模式来创建对象，不知道后面有没有相关的计划。总结本文通过一些简单的案例讨论了值类型与值对象的概念，并且探讨了不同语言对值类型的支持情况。然后对于在 Java 语言中如何创建值对象给出了一些指导原则，并介绍了一些可用于快速实现值对象的工具。值对象的使用是一种非常有用的编程技巧，可以使我们的业务语义更加清晰，并有效的简化代码逻辑的复杂程度。因此，建议大家在自己的代码中多尝试使用值对象，相信在这个过程中必然更有更深刻的认识和感受。相关链接[1].https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.2[2]. https://martinfowler.com/bliki/AliasingBug.html?spm=ata.21736010.0.0.1bf49431yt4uP0[3]. https://zhuanlan.zhihu.com/p/94568794?spm=ata.21736010.0.0.1bf49431yt4uP0[4]. http://openjdk.java.net/jeps/169?spm=ata.21736010.0.0.1bf49431yt4uP0[5]. [5].https://blogs.oracle.com/jrose/value-types-in-the-vm?spm=ata.21736010.0.0.1bf49431yt4uP0[6].https://bugs.openjdk.java.net/browse/JDK-8251554?spm=ata.21736010.0.0.1bf49431yt4uP0[7].https://bugs.openjdk.java.net/browse/JDK-8259731?spm=ata.21736010.0.0.1bf49431yt4uP0[8].https://openjdk.java.net/jeps/1?spm=ata.21736010.0.0.1bf49431yt4uP0[9].https://docs.microsoft.com/zh-cn/dotnet/csharp/language-reference/builtin-types/value-types?spm=ata.21736010.0.0.1bf49431yt4uP0[10].https://martinfowler.com/bliki/ValueObject.html?spm=ata.21736010.0.0.1bf49431yt4uP0[11].https://mapstruct.org/?spm=ata.21736010.0.0.1bf49431yt4uP0

原创｜阿里巴巴淘系技术在一个DDD架构设计中，领域层的设计合理性会直接影响整个架构的代码结构以及应用层、基础设施层的设计。但是领域层设计又是有挑战的任务，特别是在一个业务逻辑相对复杂应用中，每一个业务规则是应该放在Entity、ValueObject 还是 DomainService是值得用心思考的，既要避免未来的扩展性差，又要确保不会过度设计导致复杂性。今天我用一个相对轻松易懂的领域做一个案例演示，但在实际业务应用中，无论是交易、营销还是互动，都可以用类似的逻辑来实现。初探龙与魔法的世界架构▐ 背景和规则平日里看了好多严肃的业务代码，今天找一个轻松的话题，如何用代码实现一个龙与魔法的游戏世界的（极简）规则？基础配置如下：玩家（Player）可以是战士（Fighter）、法师（Mage）、龙骑（Dragoon）怪物（Monster）可以是兽人（Orc）、精灵（Elf）、龙（Dragon），怪物有血量武器（Weapon）可以是剑（Sword）、法杖（Staff），武器有攻击力玩家可以装备一个武器，武器攻击可以是物理类型（0），火（1），冰（2）等，武器类型决定伤害类型攻击规则如下：兽人对物理攻击伤害减半精灵对魔法攻击伤害减半龙对物理和魔法攻击免疫，除非玩家是龙骑，则伤害加倍▐ OOP实现对于熟悉Object-Oriented Programming的同学，一个比较简单的实现是通过类的继承关系（此处省略部分非核心代码）：public abstract class Player { Weapon weapon } public class Fighter extends Player {} public class Mage extends Player {} public class Dragoon extends Player {} public abstract class Monster { Long health; } public Orc extends Monster {} public Elf extends Monster {} public Dragoon extends Monster {} public abstract class Weapon { int damage; int damageType; // 0 - physical, 1 - fire, 2 - ice etc. } public Sword extends Weapon {} public Staff extends Weapon {}而实现规则代码如下：public class Player { public void attack(Monster monster) { monster.receiveDamageBy(weapon, this); } } public class Monster { public void receiveDamageBy(Weapon weapon, Player player) { this.health -= weapon.getDamage(); // 基础规则 } } public class Orc extends Monster { @Override public void receiveDamageBy(Weapon weapon, Player player) { if (weapon.getDamageType() == 0) { this.setHealth(this.getHealth() - weapon.getDamage() / 2); // Orc的物理防御规则 } else { super.receiveDamageBy(weapon, player); } } } public class Dragon extends Monster { @Override public void receiveDamageBy(Weapon weapon, Player player) { if (player instanceof Dragoon) { this.setHealth(this.getHealth() - weapon.getDamage() * 2); // 龙骑伤害规则 } // else no damage, 龙免疫力规则 } }然后跑几个单测：public class BattleTest { @Test @DisplayName("Dragon is immune to attacks") public void testDragonImmunity() { // Given Fighter fighter = new Fighter("Hero"); Sword sword = new Sword("Excalibur", 10); fighter.setWeapon(sword); Dragon dragon = new Dragon("Dragon", 100L); // When fighter.attack(dragon); // Then assertThat(dragon.getHealth()).isEqualTo(100); } @Test @DisplayName("Dragoon attack dragon doubles damage") public void testDragoonSpecial() { // Given Dragoon dragoon = new Dragoon("Dragoon"); Sword sword = new Sword("Excalibur", 10); dragoon.setWeapon(sword); Dragon dragon = new Dragon("Dragon", 100L); // When dragoon.attack(dragon); // Then assertThat(dragon.getHealth()).isEqualTo(100 - 10 * 2); } @Test @DisplayName("Orc should receive half damage from physical weapons") public void testFighterOrc() { // Given Fighter fighter = new Fighter("Hero"); Sword sword = new Sword("Excalibur", 10); fighter.setWeapon(sword); Orc orc = new Orc("Orc", 100L); // When fighter.attack(orc); // Then assertThat(orc.getHealth()).isEqualTo(100 - 10 / 2); } @Test @DisplayName("Orc receive full damage from magic attacks") public void testMageOrc() { // Given Mage mage = new Mage("Mage"); Staff staff = new Staff("Fire Staff", 10); mage.setWeapon(staff); Orc orc = new Orc("Orc", 100L); // When mage.attack(orc); // Then assertThat(orc.getHealth()).isEqualTo(100 - 10); } }以上代码和单测都比较简单，不做多余的解释了。▐ 分析OOP代码的设计缺陷编程语言的强类型无法承载业务规则以上的OOP代码可以跑得通，直到我们加一个限制条件：战士只能装备剑法师只能装备法杖这个规则在Java语言里无法通过强类型来实现，虽然Java有Variable Hiding（或者C#的new class variable），但实际上只是在子类上加了一个新变量，所以会导致以下的问题：@Data public class Fighter extends Player { private Sword weapon; } @Test public void testEquip() { Fighter fighter = new Fighter("Hero"); Sword sword = new Sword("Sword", 10); fighter.setWeapon(sword); Staff staff = new Staff("Staff", 10); fighter.setWeapon(staff); assertThat(fighter.getWeapon()).isInstanceOf(Staff.class); // 错误了 }在最后，虽然代码感觉是setWeapon(Staff)，但实际上只修改了父类的变量，并没有修改子类的变量，所以实际不生效，也不抛异常，但结果是错的。当然，可以在父类限制setter为protected，但这样就限制了父类的API，极大的降低了灵活性，同时也违背了Liskov substitution principle，即一个父类必须要cast成子类才能使用：@Data public abstract class Player { @Setter(AccessLevel.PROTECTED) private Weapon weapon; } @Test public void testCastEquip() { Fighter fighter = new Fighter("Hero"); Sword sword = new Sword("Sword", 10); fighter.setWeapon(sword); Player player = fighter; Staff staff = new Staff("Staff", 10); player.setWeapon(staff); // 编译不过，但从API层面上应该开放可用 }最后，如果规则增加一条：战士和法师都能装备匕首（dagger）BOOM，之前写的强类型代码都废了，需要重构。对象继承导致代码强依赖父类逻辑，违反开闭原则Open-Closed Principle（OCP）开闭原则（OCP）规定“对象应该对于扩展开放，对于修改封闭“，继承虽然可以通过子类扩展新的行为，但因为子类可能直接依赖父类的实现，导致一个变更可能会影响所有对象。在这个例子里，如果增加任意一种类型的玩家、怪物或武器，或增加一种规则，都有可能需要修改从父类到子类的所有方法。比如，如果要增加一个武器类型：狙击枪，能够无视所有防御一击必杀，需要修改的代码包括：WeaponPlayer和所有的子类（是否能装备某个武器的判断）Monster和所有的子类（伤害计算逻辑）public class Monster { public void receiveDamageBy(Weapon weapon, Player player) { this.health -= weapon.getDamage(); // 老的基础规则 if (Weapon instanceof Gun) { // 新的逻辑 this.setHealth(0); } } } public class Dragon extends Monster { public void receiveDamageBy(Weapon weapon, Player player) { if (Weapon instanceof Gun) { // 新的逻辑 super.receiveDamageBy(weapon, player); } // 老的逻辑省略 } } 在一个复杂的软件中为什么会建议“尽量”不要违背OCP？最核心的原因就是一个现有逻辑的变更可能会影响一些原有的代码，导致一些无法预见的影响。这个风险只能通过完整的单元测试覆盖来保障，但在实际开发中很难保障单测的覆盖率。OCP的原则能尽可能的规避这种风险，当新的行为只能通过新的字段/方法来实现时，老代码的行为自然不会变。继承虽然能Open for extension，但很难做到Closed for modification。所以今天解决OCP的主要方法是通过Composition-over-inheritance，即通过组合来做到扩展性，而不是通过继承。Player.attack(monster) 还是 Monster.receiveDamage(Weapon, Player)？在这个例子里，其实业务规则的逻辑到底应该写在哪里是有异议的：当我们去看一个对象和另一个对象之间的交互时，到底是Player去攻击Monster，还是Monster被Player攻击？目前的代码主要将逻辑写在Monster的类中，主要考虑是Monster会受伤降低Health，但如果是Player拿着一把双刃剑会同时伤害自己呢？是不是发现写在Monster类里也有问题？代码写在哪里的原则是什么？多对象行为类似，导致代码重复当我们有不同的对象，但又有相同或类似的行为时，OOP会不可避免的导致代码的重复。在这个例子里，如果我们去增加一个“可移动”的行为，需要在Player和Monster类中都增加类似的逻辑：public abstract class Player { int x; int y; void move(int targetX, int targetY) { // logic } } public abstract class Monster { int x; int y; void move(int targetX, int targetY) { // logic } }一个可能的解法是有个通用的父类：public abstract class Movable { int x; int y; void move(int targetX, int targetY) { // logic } } public abstract class Player extends Movable; public abstract class Monster extends Movable;但如果再增加一个跳跃能力Jumpable呢？一个跑步能力Runnable呢？如果Player可以Move和Jump，Monster可以Move和Run，怎么处理继承关系？要知道Java（以及绝大部分语言）是不支持多父类继承的，所以只能通过重复代码来实现。问题总结在这个案例里虽然从直觉来看OOP的逻辑很简单，但如果你的业务比较复杂，未来会有大量的业务规则变更时，简单的OOP代码会在后期变成复杂的一团浆糊，逻辑分散在各地，缺少全局视角，各种规则的叠加会触发bug。有没有感觉似曾相识？对的，电商体系里的优惠、交易等链路经常会碰到类似的坑。而这类问题的核心本质在于：业务规则的归属到底是对象的“行为”还是独立的”规则对象“？业务规则之间的关系如何处理？通用“行为”应该如何复用和维护？在讲DDD的解法前，我们先去看看一套游戏里最近比较火的架构设计，Entity-Component-System（ECS）是如何实现的。Entity-Component-System（ECS）架构简介▐ ECS介绍ECS架构模式是其实是一个很老的游戏架构设计，最早应该能追溯到《地牢围攻》的组件化设计，但最近因为Unity的加入而开始变得流行（比如《守望先锋》就是用的ECS）。要很快的理解ECS架构的价值，我们需要理解一个游戏代码的核心问题：性能：游戏必须要实现一个高的渲染率（60FPS），也就是说整个游戏世界需要在1/60s（大概16ms）内完整更新一次（包括物理引擎、游戏状态、渲染、AI等）。而在一个游戏中，通常有大量的（万级、十万级）游戏对象需要更新状态，除了渲染可以依赖GPU之外，其他的逻辑都需要由CPU完成，甚至绝大部分只能由单线程完成，导致绝大部分时间复杂场景下CPU（主要是内存到CPU的带宽）会成为瓶颈。在CPU单核速度几乎不再增加的时代，如何能让CPU处理的效率提升，是提升游戏性能的核心。代码组织：如同第一章讲的案例一样，当我们用传统OOP的模式进行游戏开发时，很容易就会陷入代码组织上的问题，最终导致代码难以阅读，维护和优化。可扩展性：这个跟上一条类似，但更多的是游戏的特性导致：需要快速更新，加入新的元素。一个游戏的架构需要能通过低代码、甚至0代码的方式增加游戏元素，从而通过快速更新而留住用户。如果每次变更都需要开发新的代码，测试，然后让用户重新下载客户端，可想而知这种游戏很难在现在的竞争环境下活下来。而ECS架构能很好的解决上面的几个问题，ECS架构主要分为：Entity：用来代表任何一个游戏对象，但是在ECS里一个Entity最重要的仅仅是他的EntityID，一个Entity里包含多个ComponentComponent：是真正的数据，ECS架构把一个个的实体对象拆分为更加细化的组件，比如位置、素材、状态等，也就是说一个Entity实际上只是一个Bag of Components。System（或者ComponentSystem，组件系统）：是真正的行为，一个游戏里可以有很多个不同的组件系统，每个组件系统都只负责一件事，可以依次处理大量的相同组件，而不需要去理解具体的Entity。所以一个ComponentSystem理论上可以有更加高效的组件处理效率，甚至可以实现并行处理，从而提升CPU利用率。ECS的一些核心性能优化包括将同类型组件放在同一个Array中，然后Entity仅保留到各自组件的pointer，这样能更好的利用CPU的缓存，减少数据的加载成本，以及SIMD的优化等。一个ECS案例的伪代码如下：由于本文不是讲解ECS架构的，感兴趣的同学可以搜索Entity-Component-System或者看看Unity的ECS文档等。▐ ECS架构分析重新回来分析ECS，其实它的本源还是几个很老的概念：组件化在软件系统里，我们通常将复杂的大系统拆分为独立的组件，来降低复杂度。比如网页里通过前端组件化降低重复开发成本，微服务架构通过服务和数据库的拆分降低服务复杂度和系统影响面等。但是ECS架构把这个走到了极致，即每个对象内部都实现了组件化。通过将一个游戏对象的数据和行为拆分为多个组件和组件系统，能实现组件的高度复用性，降低重复开发成本。行为抽离这个在游戏系统里有个比较明显的优势。如果按照OOP的方式，一个游戏对象里可能会包括移动代码、战斗代码、渲染代码、AI代码等，如果都放在一个类里会很长，且很难去维护。通过将通用逻辑抽离出来为单独的System类，可以明显提升代码的可读性。另一个好处则是抽离了一些和对象代码无关的依赖，比如上文的delta，这个delta如果是放在Entity的update方法，则需要作为入参注入，而放在System里则可以统一管理。在第一章的有个问题，到底是应该Player.attack(monster) 还是 Monster.receiveDamage(Weapon, Player)。在ECS里这个问题就变的很简单，放在CombatSystem里就可以了。数据驱动即一个对象的行为不是写死的而是通过其参数决定，通过参数的动态修改，就可以快速改变一个对象的具体行为。在ECS的游戏架构里，通过给Entity注册相应的Component，以及改变Component的具体参数的组合，就可以改变一个对象的行为和玩法，比如创建一个水壶+爆炸属性就变成了“爆炸水壶”、给一个自行车加上风魔法就变成了飞车等。在有些Rougelike游戏中，可能有超过1万件不同类型、不同功能的物品，如果这些不同功能的物品都去单独写代码，可能永远都写不完，但是通过数据驱动+组件化架构，所有物品的配置最终就是一张表，修改也极其简单。这个也是组合胜于继承原则的一次体现。▐ ECS的缺陷虽然ECS在游戏界已经开始崭露头角，我发现ECS架构目前还没有在哪个大型商业应用中被使用过。原因可能很多，包括ECS比较新大家还不了解、缺少商业成熟可用的框架、程序员们还不够能适应从写逻辑脚本到写组件的思维转变等，但我认为其最大的一个问题是ECS为了提升性能，强调了数据/状态（State）和行为（Behaivor）分离，并且为了降低GC成本，直接操作数据，走到了一个极端。而在商业应用中，数据的正确性、一致性和健壮性应该是最高的优先级，而性能只是锦上添花的东西，所以ECS很难在商业场景里带来特别大的好处。但这不代表我们不能借鉴一些ECS的突破性思维，包括组件化、跨对象行为的抽离、以及数据驱动模式，而这些在DDD里也能很好的用起来。基于DDD架构的一种解法▐ 领域对象回到我们原来的问题域上面，我们从领域层拆分一下各种对象：实体类在DDD里，实体类包含ID和内部状态，在这个案例里实体类包含Player、Monster和Weapon。Weapon被设计成实体类是因为两把同名的Weapon应该可以同时存在，所以必须要有ID来区分，同时未来也可以预期Weapon会包含一些状态，比如升级、临时的buff、耐久等。public class Player implements Movable { private PlayerId id; private String name; private PlayerClass playerClass; // enum private WeaponId weaponId; // （Note 1） private Transform position = Transform.ORIGIN; private Vector velocity = Vector.ZERO; } public class Monster implements Movable { private MonsterId id; private MonsterClass monsterClass; // enum private Health health; private Transform position = Transform.ORIGIN; private Vector velocity = Vector.ZERO; } public class Weapon { private WeaponId id; private String name; private WeaponType weaponType; // enum private int damage; private int damageType; // 0 - physical, 1 - fire, 2 - ice }在这个简单的案例里，我们可以利用enum的PlayerClass、MonsterClass来代替继承关系，后续也可以利用Type Object设计模式来做到数据驱动。Note 1: 因为 Weapon 是实体类，但是Weapon能独立存在，Player不是聚合根，所以Player只能保存WeaponId，而不能直接指向Weapon。值对象的组件化在前面的ECS架构里，有个MovementSystem的概念是可以复用的，虽然不应该直接去操作Component或者继承通用的父类，但是可以通过接口的方式对领域对象做组件化处理：pubpublic interface Movable { // 相当于组件 Transform getPosition(); Vector getVelocity(); // 行为 void moveTo(long x, long y); void startMove(long velX, long velY); void stopMove(); boolean isMoving(); } // 具体实现 public class Player implements Movable { public void moveTo(long x, long y) { this.position = new Transform(x, y); } public void startMove(long velocityX, long velocityY) { this.velocity = new Vector(velocityX, velocityY); } public void stopMove() { this.velocity = Vector.ZERO; } @Override public boolean isMoving() { return this.velocity.getX() != 0 || this.velocity.getY() != 0; } } @Value public class Transform { public static final Transform ORIGIN = new Transform(0, 0); long x; long y; } @Value public class Vector { public static final Vector ZERO = new Vector(0, 0); long x; long y; }注意两点：Moveable的接口没有Setter。一个Entity的规则是不能直接变更其属性，必须通过Entity的方法去对内部状态做变更。这样能保证数据的一致性。抽象Movable的好处是如同ECS一样，一些特别通用的行为（如在大地图里移动）可以通过统一的System代码去处理，避免了重复劳动。▐ 装备行为因为我们已经不会用Player的子类来决定什么样的Weapon可以装备，所以这段逻辑应该被拆分到一个单独的类里。这种类在DDD里被叫做领域服务（Domain Service）。public interface EquipmentService { boolean canEquip(Player player, Weapon weapon); }在DDD里，一个Entity不应该直接参考另一个Entity或服务，也就是说以下的代码是错误的：public class Player { @Autowired EquipmentService equipmentService; // BAD: 不可以直接依赖 public void equip(Weapon weapon) { // ... } }这里的问题是Entity只能保留自己的状态（或非聚合根的对象）。任何其他的对象，无论是否通过依赖注入的方式弄进来，都会破坏Entity的Invariance，并且还难以单测。正确的引用方式是通过方法参数引入（Double Dispatch）：public class Player { public void equip(Weapon weapon, EquipmentService equipmentService) { if (equipmentService.canEquip(this, weapon)) { this.weaponId = weapon.getId(); } else { throw new IllegalArgumentException("Cannot Equip: " + weapon); } } }在这里，无论是Weapon还是EquipmentService都是通过方法参数传入，确保不会污染Player的自有状态。Double Dispatch是一个使用Domain Service经常会用到的方法，类似于调用反转。然后在EquipmentService里实现相关的逻辑判断，这里我们用了另一个常用的Strategy（或者叫Policy）设计模式：public class EquipmentServiceImpl implements EquipmentService { private EquipmentManager equipmentManager; @Override public boolean canEquip(Player player, Weapon weapon) { return equipmentManager.canEquip(player, weapon); } } // 策略优先级管理 public class EquipmentManager { private static final List<EquipmentPolicy> POLICIES = new ArrayList<>(); static { POLICIES.add(new FighterEquipmentPolicy()); POLICIES.add(new MageEquipmentPolicy()); POLICIES.add(new DragoonEquipmentPolicy()); POLICIES.add(new DefaultEquipmentPolicy()); } public boolean canEquip(Player player, Weapon weapon) { for (EquipmentPolicy policy : POLICIES) { if (!policy.canApply(player, weapon)) { continue; } return policy.canEquip(player, weapon); } return false; } } // 策略案例 public class FighterEquipmentPolicy implements EquipmentPolicy { @Override public boolean canApply(Player player, Weapon weapon) { return player.getPlayerClass() == PlayerClass.Fighter; } /** * Fighter能装备Sword和Dagger */ @Override public boolean canEquip(Player player, Weapon weapon) { return weapon.getWeaponType() == WeaponType.Sword || weapon.getWeaponType() == WeaponType.Dagger; } } // 其他策略省略，见源码这样设计的最大好处是未来的规则增加只需要添加新的Policy类，而不需要去改变原有的类。▐ 攻击行为在上文中曾经有提起过，到底应该是Player.attack(Monster)还是Monster.receiveDamage(Weapon, Player)？在DDD里，因为这个行为可能会影响到Player、Monster和Weapon，所以属于跨实体的业务逻辑。在这种情况下需要通过一个第三方的领域服务（Domain Service）来完成。public interface CombatService { void performAttack(Player player, Monster monster); } public class CombatServiceImpl implements CombatService { private WeaponRepository weaponRepository; private DamageManager damageManager; @Override public void performAttack(Player player, Monster monster) { Weapon weapon = weaponRepository.find(player.getWeaponId()); int damage = damageManager.calculateDamage(player, weapon, monster); if (damage > 0) { monster.takeDamage(damage); // （Note 1）在领域服务里变更Monster } // 省略掉Player和Weapon可能受到的影响 } }同样的在这个案例里，可以通过Strategy设计模式来解决damage的计算问题：// 策略优先级管理 public class DamageManager { private static final List<DamagePolicy> POLICIES = new ArrayList<>(); static { POLICIES.add(new DragoonPolicy()); POLICIES.add(new DragonImmunityPolicy()); POLICIES.add(new OrcResistancePolicy()); POLICIES.add(new ElfResistancePolicy()); POLICIES.add(new PhysicalDamagePolicy()); POLICIES.add(new DefaultDamagePolicy()); } public int calculateDamage(Player player, Weapon weapon, Monster monster) { for (DamagePolicy policy : POLICIES) { if (!policy.canApply(player, weapon, monster)) { continue; } return policy.calculateDamage(player, weapon, monster); } return 0; } } // 策略案例 public class DragoonPolicy implements DamagePolicy { public int calculateDamage(Player player, Weapon weapon, Monster monster) { return weapon.getDamage() * 2; } @Override public boolean canApply(Player player, Weapon weapon, Monster monster) { return player.getPlayerClass() == PlayerClass.Dragoon && monster.getMonsterClass() == MonsterClass.Dragon; } }特别需要注意的是这里的CombatService领域服务和3.2的EquipmentService领域服务，虽然都是领域服务，但实质上有很大的差异。上文的EquipmentService更多的是提供只读策略，且只会影响单个对象，所以可以在Player.equip方法上通过参数注入。但是CombatService有可能会影响多个对象，所以不能直接通过参数注入的方式调用。▐ 单元测试@@Test @DisplayName("Dragoon attack dragon doubles damage") public void testDragoonSpecial() { // Given Player dragoon = playerFactory.createPlayer(PlayerClass.Dragoon, "Dart"); Weapon sword = weaponFactory.createWeaponFromPrototype(swordProto, "Soul Eater", 60); ((WeaponRepositoryMock)weaponRepository).cache(sword); dragoon.equip(sword, equipmentService); Monster dragon = monsterFactory.createMonster(MonsterClass.Dragon, 100); // When combatService.performAttack(dragoon, dragon); // Then assertThat(dragon.getHealth()).isEqualTo(Health.ZERO); assertThat(dragon.isAlive()).isFalse(); } @Test @DisplayName("Orc should receive half damage from physical weapons") public void testFighterOrc() { // Given Player fighter = playerFactory.createPlayer(PlayerClass.Fighter, "MyFighter"); Weapon sword = weaponFactory.createWeaponFromPrototype(swordProto, "My Sword"); ((WeaponRepositoryMock)weaponRepository).cache(sword); fighter.equip(sword, equipmentService); Monster orc = monsterFactory.createMonster(MonsterClass.Orc, 100); // When combatService.performAttack(fighter, orc); // Then assertThat(orc.getHealth()).isEqualTo(Health.of(100 - 10 / 2)); }具体的代码比较简单，解释省略▐ 移动系统最后还有一种Domain Service，通过组件化，我们其实可以实现ECS一样的System，来降低一些重复性的代码：public class MovementSystem { private static final long X_FENCE_MIN = -100; private static final long X_FENCE_MAX = 100; private static final long Y_FENCE_MIN = -100; private static final long Y_FENCE_MAX = 100; private List<Movable> entities = new ArrayList<>(); public void register(Movable movable) { entities.add(movable); } public void update() { for (Movable entity : entities) { if (!entity.isMoving()) { continue; } Transform old = entity.getPosition(); Vector vel = entity.getVelocity(); long newX = Math.max(Math.min(old.getX() + vel.getX(), X_FENCE_MAX), X_FENCE_MIN); long newY = Math.max(Math.min(old.getY() + vel.getY(), Y_FENCE_MAX), Y_FENCE_MIN); entity.moveTo(newX, newY); } } }单测：@Test @DisplayName("Moving player and monster at the same time") public void testMovement() { // Given Player fighter = playerFactory.createPlayer(PlayerClass.Fighter, "MyFighter"); fighter.moveTo(2, 5); fighter.startMove(1, 0); Monster orc = monsterFactory.createMonster(MonsterClass.Orc, 100); orc.moveTo(10, 5); orc.startMove(-1, 0); movementSystem.register(fighter); movementSystem.register(orc); // When movementSystem.update(); // Then assertThat(fighter.getPosition().getX()).isEqualTo(2 + 1); assertThat(orc.getPosition().getX()).isEqualTo(10 - 1); }在这里MovementSystem就是一个相对独立的Domain Service，通过对Movable的组件化，实现了类似代码的集中化、以及一些通用依赖/配置的中心化（如X、Y边界等）。DDD领域层的一些设计规范上面我主要针对同一个例子对比了OOP、ECS和DDD的3种实现，比较如下：基于继承关系的OOP代码：OOP的代码最好写，也最容易理解，所有的规则代码都写在对象里，但是当领域规则变得越来越复杂时，其结构会限制它的发展。新的规则有可能会导致代码的整体重构。基于组件化的ECS代码：ECS代码有最高的灵活性、可复用性、及性能，但极具弱化了实体类的内聚，所有的业务逻辑都写在了服务里，会导致业务的一致性无法保障，对商业系统会有较大的影响。基于领域对象 + 领域服务的DDD架构：DDD的规则其实最复杂，同时要考虑到实体类的内聚和保证不变性（Invariants），也要考虑跨对象规则代码的归属，甚至要考虑到具体领域服务的调用方式，理解成本比较高。所以下面，我会尽量通过一些设计规范，来降低DDD领域层的设计成本。领域层里的Value Object（Domain Primitive）设计规范请参考我之前的文章。▐ 实体类（Entity）大多数DDD架构的核心都是实体类，实体类包含了一个领域里的状态、以及对状态的直接操作。Entity最重要的设计原则是保证实体的不变性（Invariants），也就是说要确保无论外部怎么操作，一个实体内部的属性都不能出现相互冲突，状态不一致的情况。所以几个设计原则如下：创建即一致在贫血模型里，通常见到的代码是一个模型通过手动new出来之后，由调用方一个参数一个参数的赋值，这就很容易产生遗漏，导致实体状态不一致。所以DDD里实体创建的方法有两种：constructor参数要包含所有必要属性，或者在constructor里有合理的默认值。比如，账号的创建：public class Account { private String accountNumber; private Long amount; } @Test public void test() { Account account = new Account(); account.setAmount(100L); TransferService.transfer(account); // 报错了，因为Account缺少必要的AccountNumber }如果缺少一个强校验的constructor，就无法保障创建的实体的一致性。所以需要增加一个强校验的constructor：public class Account { public Account(String accountNumber, Long amount) { assert StringUtils.isNotBlank(accountNumber); assert amount >= 0; this.accountNumber = accountNumber; this.amount = amount; } } @Test public void test() { Account account = new Account("123", 100L); // 确保对象的有效性 }使用Factory模式来降低调用方复杂度另一种方法是通过Factory模式来创建对象，降低一些重复性的入参。比如：public class WeaponFactory { public Weapon createWeaponFromPrototype(WeaponPrototype proto, String newName) { Weapon weapon = new Weapon(null, newName, proto.getWeaponType(), proto.getDamage(), proto.getDamageType()); return weapon; } }通过传入一个已经存在的Prototype，可以快速的创建新的实体。还有一些其他的如Builder等设计模式就不一一指出了。尽量避免public setter一个最容易导致不一致性的原因是实体暴露了public的setter方法，特别是set单一参数会导致状态不一致的情况。比如，一个订单可能包含订单状态（下单、已支付、已发货、已收货）、支付单、物流单等子实体，如果一个调用方能随意去set订单状态，就有可能导致订单状态和子实体匹配不上，导致业务流程走不通的情况。所以在实体里，需要通过行为方法来修改内部状态：@Data @Setter(AccessLevel.PRIVATE) // 确保不生成public setter public class Order { private int status; // 0 - 创建，1 - 支付，2 - 发货，3 - 收货 private Payment payment; // 支付单 private Shipping shipping; // 物流单 public void pay(Long userId, Long amount) { if (status != 0) { throw new IllegalStateException(); } this.status = 1; this.payment = new Payment(userId, amount); } public void ship(String trackingNumber) { if (status != 1) { throw new IllegalStateException(); } this.status = 2; this.shipping = new Shipping(trackingNumber); } }【建议】在有些简单场景里，有时候确实可以比较随意的设置一个值而不会导致不一致性，也建议将方法名重新写为比较“行为化”的命名，会增强其语意。比如setPosition(x, y)可以叫做moveTo(x, y)，setAddress可以叫做assignAddress等。通过聚合根保证主子实体的一致性在稍微复杂一点的领域里，通常主实体会包含子实体，这时候主实体就需要起到聚合根的作用，即：子实体不能单独存在，只能通过聚合根的方法获取到。任何外部的对象都不能直接保留子实体的引用子实体没有独立的Repository，不可以单独保存和取出，必须要通过聚合根的Repository实例化子实体可以单独修改自身状态，但是多个子实体之间的状态一致性需要聚合根来保障常见的电商域中聚合的案例如主子订单模型、商品/SKU模型、跨子订单优惠、跨店优惠模型等。很多聚合根和Repository的设计规范在我前面一篇关于Repository的文章中已经详细解释过，可以拿来参考。不可以强依赖其他聚合根实体或领域服务一个实体的原则是高内聚、低耦合，即一个实体类不能直接在内部直接依赖一个外部的实体或服务。这个原则和绝大多数ORM框架都有比较严重的冲突，所以是一个在开发过程中需要特别注意的。这个原则的必要原因包括：对外部对象的依赖性会直接导致实体无法被单测；以及一个实体无法保证外部实体变更后不会影响本实体的一致性和正确性。所以，正确的对外部依赖的方法有两种：只保存外部实体的ID：这里我再次强烈建议使用强类型的ID对象，而不是Long型ID。强类型的ID对象不单单能自我包含验证代码，保证ID值的正确性，同时还能确保各种入参不会因为参数顺序变化而出bug。具体可以参考我的Domain Primitive文章。针对于“无副作用”的外部依赖，通过方法入参的方式传入。比如上文中的equip(Weapon，EquipmentService）方法。如果方法对外部依赖有副作用，不能通过方法入参的方式，只能通过Domain Service解决，见下文。任何实体的行为只能直接影响到本实体（和其子实体）这个原则更多是一个确保代码可读性、可理解的原则，即任何实体的行为不能有“直接”的”副作用“，即直接修改其他的实体类。这么做的好处是代码读下来不会产生意外。另一个遵守的原因是可以降低未知的变更的风险。在一个系统里一个实体对象的所有变更操作应该都是预期内的，如果一个实体能随意被外部直接修改的话，会增加代码bug的风险。▐ 领域服务（Domain Service）在上文讲到，领域服务其实也分很多种，在这里根据上文总结出来三种常见的：单对象策略型这种领域对象主要面向的是单个实体对象的变更，但涉及到多个领域对象或外部依赖的一些规则。在上文中，EquipmentService即为此类：变更的对象是Player的参数读取的是Player和Weapon的数据，可能还包括从外部读取一些数据在这种类型下，实体应该通过方法入参的方式传入这种领域服务，然后通过Double Dispatch来反转调用领域服务的方法，比如：Player.equip(Weapon, EquipmentService) { EquipmentService.canEquip(this, Weapon); }为什么这种情况下不能先调用领域服务，再调用实体对象的方法，从而减少实体对领域服务的入参型依赖呢？比如，下面这个方法是错误的：boolean canEquip = EquipmentService.canEquip(Player, Weapon); if (canEquip) { Player.equip(Weapon); // ❌，这种方法不可行，因为这个方法有不一致的可能性 }其错误的主要原因是缺少了领域服务入参会导致方法有可能产生不一致的情况。跨对象事务型当一个行为会直接修改多个实体时，不能再通过单一实体的方法作处理，而必须直接使用领域服务的方法来做操作。在这里，领域服务更多的起到了跨对象事务的作用，确保多个实体的变更之间是有一致性的。在上文里，虽然以下的代码虽然可以跑到通，但是是不建议的：public class Player { void attack(Monster, CombatService) { CombatService.performAttack(this, Monster); // ❌，不要这么写，会导致副作用 } }而我们真实调用应该直接调用CombatService的方法：public void test() { //... combatService.performAttack(mage, orc); }这个原则也映射了4.1.5 的原则，即Player.attack会直接影响到Monster，但这个调用Monster又没有感知。通用组件型这种类型的领域服务更像ECS里的System，提供了组件化的行为，但本身又不直接绑死在一种实体类上。具体案例可以参考上文中的MovementSystem实现。▐ 策略对象（Domain Policy）Policy或者Strategy设计模式是一个通用的设计模式，但是在DDD架构中会经常出现，其核心就是封装领域规则。一个Policy是一个无状态的单例对象，通常需要至少2个方法：canApply 和 一个业务方法。其中，canApply方法用来判断一个Policy是否适用于当前的上下文，如果适用则调用方会去触发业务方法。通常，为了降低一个Policy的可测试性和复杂度，Policy不应该直接操作对象，而是通过返回计算后的值，在Domain Service里对对象进行操作。在上文案例里，DamagePolicy只负责计算应该受到的伤害，而不是直接对Monster造成伤害。这样除了可测试外，还为未来的多Policy叠加计算做了准备。除了本文里静态注入多个Policy以及手动排优先级之外，在日常开发中经常能见到通过Java的SPI机制或类SPI机制注册Policy，以及通过不同的Priority方案对Policy进行排序，在这里就不作太多的展开了。加餐 - 副作用的处理方法 - 领域事件在上文中，有一种类型的领域规则被我刻意忽略了，那就是”副作用“。一般的副作用发生在核心领域模型状态变更后，同步或者异步对另一个对象的影响或行为。在这个案例里，我们可以增加一个副作用规则：当Monster的生命值降为0后，给Player奖励经验值这种问题有很多种解法，比如直接把副作用写在CombatService里：public class CombatService { public void performAttack(Player player, Monster monster) { // ... monster.takeDamage(damage); if (!monster.isAlive()) { player.receiveExp(10); // 收到经验 } } }但是这样写的问题是：很快CombatService的代码就会变得很复杂，比如我们再加一个副作用：当Player的exp达到100时，升一级这时我们的代码就会变成：public class CombatService { public void performAttack(Player player, Monster monster) { // ... monster.takeDamage(damage); if (!monster.isAlive()) { player.receiveExp(10); // 收到经验 if (player.canLevelUp()) { player.levelUp(); // 升级 } } } }如果再加上“升级后奖励XXX”呢？“更新XXX排行”呢？依此类推，后续这种代码将无法维护。所以我们需要介绍一下领域层最后一个概念：领域事件（Domain Event）。▐ 领域事件介绍领域事件是一个在领域里发生了某些事后，希望领域里其他对象能够感知到的通知机制。在上面的案例里，代码之所以会越来越复杂，其根本的原因是反应代码（比如升级）直接和上面的事件触发条件（比如收到经验）直接耦合，而且这种耦合性是隐性的。领域事件的好处就是将这种隐性的副作用“显性化”，通过一个显性的事件，将事件触发和事件处理解耦，最终起到代码更清晰、扩展性更好的目的。所以，领域事件是在DDD里，比较推荐使用的跨实体“副作用”传播机制。▐ 领域事件实现和消息队列中间件不同的是，领域事件通常是立即执行的、在同一个进程内、可能是同步或异步。我们可以通过一个EventBus来实现进程内的通知机制，简单实现如下：// 实现者：瑜进 2019/11/28 public class EventBus { // 注册器 @Getter private final EventRegistry invokerRegistry = new EventRegistry(this); // 事件分发器 private final EventDispatcher dispatcher = new EventDispatcher(ExecutorFactory.getDirectExecutor()); // 异步事件分发器 private final EventDispatcher asyncDispatcher = new EventDispatcher(ExecutorFactory.getThreadPoolExecutor()); // 事件分发 public boolean dispatch(Event event) { return dispatch(event, dispatcher); } // 异步事件分发 public boolean dispatchAsync(Event event) { return dispatch(event, asyncDispatcher); } // 内部事件分发 private boolean dispatch(Event event, EventDispatcher dispatcher) { checkEvent(event); // 1.获取事件数组 Set<Invoker> invokers = invokerRegistry.getInvokers(event); // 2.一个事件可以被监听N次，不关心调用结果 dispatcher.dispatch(event, invokers); return true; } // 事件总线注册 public void register(Object listener) { if (listener == null) { throw new IllegalArgumentException("listener can not be null!"); } invokerRegistry.register(listener); } private void checkEvent(Event event) { if (event == null) { throw new IllegalArgumentException("event"); } if (!(event instanceof Event)) { throw new IllegalArgumentException("Event type must by " + Event.class); } } }调用方式：public class LevelUpEvent implements Event { private Player player; } public class LevelUpHandler { public void handle(Player player); } public class Player { public void receiveExp(int value) { this.exp += value; if (this.exp >= 100) { LevelUpEvent event = new LevelUpEvent(this); EventBus.dispatch(event); this.exp = 0; } } } @Test public void test() { EventBus.register(new LevelUpHandler()); player.setLevel(1); player.receiveExp(100); assertThat(player.getLevel()).equals(2); }▐ 目前领域事件的缺陷和展望从上面代码可以看出来，领域事件的很好的实施依赖EventBus、Dispatcher、Invoker这些属于框架级别的支持。同时另一个问题是因为Entity不能直接依赖外部对象，所以EventBus目前只能是一个全局的Singleton，而大家都应该知道全局Singleton对象很难被单测。这就容易导致Entity对象无法被很容易的被完整单测覆盖全。另一种解法是侵入Entity，对每个Entity增加一个List:public class Player { List<Event> events; public void receiveExp(int value) { this.exp += value; if (this.exp >= 100) { LevelUpEvent event = new LevelUpEvent(this); events.add(event); // 把event加进去 this.exp = 0; } } } @Test public void test() { EventBus.register(new LevelUpHandler()); player.setLevel(1); player.receiveExp(100); for(Event event: player.getEvents()) { // 在这里显性的dispatch事件 EventBus.dispatch(event); } assertThat(player.getLevel()).equals(2); }但是能看出来这种解法不但会侵入实体本身，同时也需要比较啰嗦的显性在调用方dispatch事件，也不是一个好的解决方案。也许未来会有一个框架能让我们既不依赖全局Singleton，也不需要显性去处理事件，但目前的方案基本都有或多或少的缺陷，大家在使用中可以注意。总结在真实的业务逻辑里，我们的领域模型或多或少的都有一定的“特殊性”，如果100%的要符合DDD规范可能会比较累，所以最主要的是梳理一个对象行为的影响面，然后作出设计决策，即：是仅影响单一对象还是多个对象，规则未来的拓展性、灵活性，性能要求，副作用的处理，等等当然，很多时候一个好的设计是多种因素的取舍，需要大家有一定的积累，真正理解每个架构背后的逻辑和优缺点。一个好的架构师不是有一个正确答案，而是能从多个方案中选出一个最平衡的方案。

在当前的不少电商或者物流等应用程序中，为了清晰的表明某些事件的当前状态，以及历史时序记录情况，经常可以看到一个步骤条控件，它分成几个节点，每个节点代表一个核心状态，每个状态之间通过线条进行连接，以经过的节点高亮显示，未经过的线条灰度显示。其中，每个节点下可以通过文字进行简要的描述。本文将利用C#中的GDI+技术，自动绘制相关的UI元素，实现Window Form的步骤条控件。1 项目结构     利用Visual Studio 社区版，创建一个Window应用程序项目WinControls，其中在资源文件中添加一个图形，用于绘制经过步骤条节点的✔ 状态。并添加几个类，具体项目结构如下图所示：其中的check_lightblue.png图片代表的是✔ 状态。可以通过Properties.Resources.check_lightblue进行访问。eumStepState.cs是一个枚举类型，表示节点的状态信息，核心代码如下：namespace WinControls { public enum eumStepState { Waiting, Completed, OutTime } }而 StepEntity.cs 文件是代表一个步骤条节点的实体对象，其中具备的属性有节点ID，节点名称，节点状态，节点顺序，节点描述等，核心代码如下：using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace WinControls { public class StepEntity { public string Id { get; set; } public string StepName { get; set; } public int StepOrder { get; set; } public eumStepState StepState { get; set; } public string StepDesc { get; set; } public object StepTag { get; set; } public StepEntity(string id, string stepname, int steporder, string stepdesc, eumStepState stepstate, object tag) { this.Id = id; this.StepName = stepname; this.StepOrder = steporder; this.StepDesc = stepdesc; this.StepTag = tag; this.StepState = stepstate; } } } 2 步骤条实现     在项目WinControls中添加一个名为StepViewer的用户控件，具体如下图所示：核心代码如下：using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Threading.Tasks; using System.Windows.Forms; namespace WinControls { public partial class StepViewer : UserControl { public StepViewer() { InitializeComponent(); this.Height = 68; this.Paint += StepViewer_Paint; } private List<StepEntity> _dataSourceList = null; private Color _Gray = Color.FromArgb(189, 195, 199); private Color _DarkGray = Color.FromArgb(149, 165, 166); private Color _Blue = Color.FromArgb(52, 152, 219); private Color _Red = Color.FromArgb(231, 76, 60); [Browsable(true), Category("StepViewer")] public List<StepEntity> ListDataSource { get { return _dataSourceList; } set { if (_dataSourceList != value) { _dataSourceList = value; Invalidate(); } } } private int _currentStep = 0; public int CurrentStep { get { return _currentStep; } set { if (_currentStep != value) { _currentStep = value; Invalidate(); } } } private void StepViewer_Paint(object sender, PaintEventArgs e) { if (this.ListDataSource != null) { int CenterY = this.Height / 2; int index = 1; int count = ListDataSource.Count; int lineWidth = 120; int StepNodeWH = 28; //this.Width = 32 * count + lineWidth * (count - 1) + 6+300; //defalut pen & brush e.Graphics.SmoothingMode = System.Drawing.Drawing2D.SmoothingMode.HighQuality; Brush brush = new SolidBrush(_Gray); Pen p = new Pen(brush, 1f); Brush brushNode = new SolidBrush(_DarkGray); Pen penNode = new Pen(brushNode, 1f); Brush brushNodeCompleted = new SolidBrush(_Blue); Pen penNodeCompleted = new Pen(brushNodeCompleted, 1f); int initX = 6; //string Font nFont = new Font("微软雅黑", 12); Font stepFont = new Font("微软雅黑", 11, FontStyle.Bold); int NodeNameWidth = 0; foreach (var item in ListDataSource) { //round Rectangle rec = new Rectangle(initX, CenterY - StepNodeWH / 2, StepNodeWH, StepNodeWH); if (CurrentStep == item.StepOrder) { if (item.StepState == eumStepState.OutTime) { e.Graphics.DrawEllipse(new Pen(_Red, 1f), rec); e.Graphics.FillEllipse(new SolidBrush(_Red), rec); } else { e.Graphics.DrawEllipse(penNodeCompleted, rec); e.Graphics.FillEllipse(brushNodeCompleted, rec); } //白色字体 SizeF fTitle = e.Graphics.MeasureString(index.ToString(), stepFont); Point pTitle = new Point(initX + StepNodeWH / 2 - (int)Math.Round(fTitle.Width) / 2, CenterY - (int)Math.Round(fTitle.Height / 2)); e.Graphics.DrawString(index.ToString(), stepFont, Brushes.White, pTitle); //nodeName SizeF sNode = e.Graphics.MeasureString(item.StepName, nFont); Point pNode = new Point(initX + StepNodeWH, CenterY - (int)Math.Round(sNode.Height / 2) + 2); e.Graphics.DrawString(item.StepName, new Font(nFont, FontStyle.Bold), brushNode, pNode); NodeNameWidth = (int)Math.Round(sNode.Width); if (index < count) { e.Graphics.DrawLine(p, initX + StepNodeWH + NodeNameWidth, CenterY, initX + StepNodeWH + NodeNameWidth + lineWidth, CenterY); } } else if (item.StepOrder < CurrentStep) { //completed e.Graphics.DrawEllipse(penNodeCompleted, rec); //image RectangleF recRF = new RectangleF(rec.X + 6, rec.Y + 6, rec.Width - 12, rec.Height - 12); e.Graphics.DrawImage(Properties.Resources.check_lightblue, recRF); //nodeName SizeF sNode = e.Graphics.MeasureString(item.StepName, nFont); Point pNode = new Point(initX + StepNodeWH, CenterY - (int)Math.Round(sNode.Height / 2) + 2); e.Graphics.DrawString(item.StepName, nFont, brushNode, pNode); NodeNameWidth = (int)Math.Round(sNode.Width); if (index < count) { e.Graphics.DrawLine(penNodeCompleted, initX + StepNodeWH + NodeNameWidth, CenterY, initX + StepNodeWH + NodeNameWidth + lineWidth, CenterY); } } else { e.Graphics.DrawEllipse(p, rec); // SizeF fTitle = e.Graphics.MeasureString(index.ToString(), stepFont); Point pTitle = new Point(initX + StepNodeWH / 2 - (int)Math.Round(fTitle.Width) / 2, CenterY - (int)Math.Round(fTitle.Height / 2)); e.Graphics.DrawString(index.ToString(), stepFont, brush, pTitle); //nodeName SizeF sNode = e.Graphics.MeasureString(item.StepName, nFont); Point pNode = new Point(initX + StepNodeWH, CenterY - (int)Math.Round(sNode.Height / 2) + 2); e.Graphics.DrawString(item.StepName, nFont, brushNode, pNode); NodeNameWidth = (int)Math.Round(sNode.Width); if (index < count) { //line e.Graphics.DrawLine(p, initX + StepNodeWH + NodeNameWidth, CenterY, initX + StepNodeWH + NodeNameWidth + lineWidth, CenterY); } } //描述信息 if (item.StepDesc != "") { Point pNode = new Point(initX + StepNodeWH, CenterY + 10); e.Graphics.DrawString(item.StepDesc, new Font(nFont.FontFamily, 10), brush, pNode); } index++; //8 is space width initX = initX + lineWidth + StepNodeWH + NodeNameWidth + 8; } } } } }其中，首先定义了一组颜色，代码如下： private Color _Gray = Color.FromArgb(189, 195, 199); private Color _DarkGray = Color.FromArgb(149, 165, 166); private Color _Blue = Color.FromArgb(52, 152, 219); private Color _Red = Color.FromArgb(231, 76, 60);其次，由于步骤条的节点有多个，是一个列表，因此这里用private List<StepEntity> _dataSourceList = null;进行定义一个数据源。[Browsable(true), Category("StepViewer")]则表示ListDataSource属性在控件的属性列表中可见。在赋值后会调用 Invalidate()方法进行UI重绘。再次，此控件初始化时，执行如下代码： public StepViewer() { InitializeComponent(); this.Height = 68; this.Paint += StepViewer_Paint; }即限定控件的高度为68，同时绑定绘制事件Paint，实现绘制的方法为 StepViewer_Paint，这是控件的核心，其中使用了  e.Graphics下的API可以绘制圆形，线条和图片，以及文本信息。3 步骤条效果     将控件添加到Form1窗口上并在初始化方法中维护数据源信息，核心代码如下：using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Threading.Tasks; using System.Windows.Forms; namespace WinControls { public partial class Form1 : Form { public Form1() { InitializeComponent(); this.BackColor = Color.White; } private void Form1_Load(object sender, EventArgs e) { List<StepEntity> list = new List<StepEntity>(); list.Add(new StepEntity("1", "新开单", 1, "这里是该步骤的描述信息", eumStepState.Completed, null)); list.Add(new StepEntity("2", "主管审批", 2, "这里是该步骤的描述信息", eumStepState.Waiting, null)); list.Add(new StepEntity("3", "总经理审批", 3, "这里是该步骤的描述信息", eumStepState.OutTime, null)); list.Add(new StepEntity("2", "完成", 4, "这里是该步骤的描述信息", eumStepState.Waiting, null)); this.stepViewer1.CurrentStep = 3; this.stepViewer1.ListDataSource = list; } private void button1_Click(object sender, EventArgs e) { this.stepViewer1.CurrentStep--; } private void button2_Click(object sender, EventArgs e) { this.stepViewer1.CurrentStep++; } } } 执行项目，Form1界面具体如下图所示：

WPF中的控件，有不少都是需要绑定数据的，例如ComboBox控件可以绑定数据，从下拉列表中进行选择。默认情况下，ComboBox控件绑定的数据从显示上比较单一，只能显示固定的文本信息。而为了更好的突出数据展现效果，这里需要使用到WPF中的另一种强大的功能，即数据模板（DataTemplate ）。 控件的数据模板为定义数据的展现提供了强大的灵活性。 WPF 控件具有支持自定义数据展现的内置功能。为了更好的介绍控件的数据模板功能，下面给出一个具体的示例，用数据模板来自定义ComboBox控件的UI显示效果，让其下拉框列表可以同时显示多个属性值，其中包含图片信息。1 WPF项目结构 首先，新建一个WPF应用程序WpfAppDemo，并新建一个images文件夹，在images文件夹中上传图片素材，项目结构如下：注意：其中的三个图片素材依次选中，并设置其资源输出生成操作为内容。具体如下图所示：2 WPF代码实现 在主界面MainWindow.xaml文件中添加一个Label、ComboBox 和Button控件,如下图：主界面MainWindow.xaml代码如下所示：<Window x:Class="WpfAppDemo.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:local="clr-namespace:WpfAppDemo" mc:Ignorable="d" Title="MainWindow" Height="320" Width="520"> <Grid> <ComboBox x:Name="myColorComBox" HorizontalAlignment="Left" Margin="110,79,0,0" VerticalAlignment="Top" Width="309" Height="48" > <!--ItemTemplate--> <ComboBox.ItemTemplate> <!--DataTemplate开始--> <DataTemplate> <Grid> <Grid.ColumnDefinitions> <ColumnDefinition Width="36"/> <ColumnDefinition Width="100*"/> </Grid.ColumnDefinitions> <Grid.RowDefinitions> <RowDefinition Height="50*"/> <RowDefinition Height="50*"/> </Grid.RowDefinitions> <!--绑定数据对象Image属性--> <Image Source="{Binding Image}" Width="32" Height="32" Margin="3,3,3,3" Grid.Row="0" Grid.Column="0" Grid.RowSpan="2" /> <!--绑定数据对象Name属性--> <TextBlock Text="{Binding Name}" FontSize="12" Grid.Row="0" Grid.Column="1" HorizontalAlignment="Left" VerticalAlignment="Center"/> <!--绑定数据对象Desc属性--> <TextBlock Text="{Binding Desc}" FontSize="10" Grid.Row="1" Grid.Column="1" HorizontalAlignment="Left" VerticalAlignment="Center"/> </Grid> </DataTemplate> <!--DataTemplate结束--> </ComboBox.ItemTemplate> </ComboBox> <Label Content="员工: " HorizontalAlignment="Left" Margin="66,92,0,0" VerticalAlignment="Top"/> <Button Content="显示" HorizontalAlignment="Left" Margin="110,166,0,0" VerticalAlignment="Top" Width="75" Height="22" Click="Button_Click"/> </Grid> </Window> ComboBox.ItemTemplate标签下有一个DataTemplate标签，其中内置了数据模板的相关元素，里面用到了Grid布局，其中将图片和文本信息依次绑定到Image对象和TextBlock对象上。其中的数据绑定由后台代码进行定义，后台代码示意如下：using System; using System.Collections.Generic; using System.Windows; namespace WpfAppDemo { public partial class MainWindow : Window { public MainWindow() { InitializeComponent(); //初始化数据，并绑定 LodData(); } private void LodData() { IList<empoyee> customList = new List<empoyee>(); //项目文件中新建一个images文件夹，并上传了001.png，002.png,003.png customList.Add(new empoyee() { ID = "001", Name = "Jack", Image = "images/001.jpg", Desc = "描述信息1" }); customList.Add(new empoyee() { ID = "002", Name = "Smith", Image = "images/002.jpg", Desc = "描述信息2" }); customList.Add(new empoyee() { ID = "003", Name = "Json", Image = "images/003.jpg", Desc = "描述信息3" }); this.myColorComBox.ItemsSource = customList;//数据源绑定 this.myColorComBox.SelectedValue = customList[1];//默认选择项 } private void Button_Click(object sender, RoutedEventArgs e) { //显示选择的员工ID信息 MessageBox.Show((this.myColorComBox.SelectedItem as empoyee).ID); } } //定义员工类 public class empoyee { public string ID { get; set; } public string Name { get; set; } public string Image { get; set; } public string Desc { get; set; } } } 其中在窗体加载过程中，调用LoadData()方法来加载数据，并通过this.myColorComBox.ItemsSource = customList进行数据源绑定。每个数据项是empoyee类的实例，有4个属性。3 效果演示 编译运行，如果运气不错的话，应该能看到如下的界面：

短信发送是软件开发中的一个常见功能，在国内常用于基于短信验证码的用户注册、找回密码和操作授权等场景。阿里云的短信服务在调用时需要实现一个不是那么容易的签名算法，但如果只是为了发送短信这一个功能就去引用其提供的 SDK 显得非常不经济。同时该 SDK 并未对 .NET 5 进行适配，编译时会提示警告信息：warning NU1701: 已使用“.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8”而不是项目目标框架“.NETStandard,Version=v2.0”还原包“BouncyCastle 1.8.6.1”。此包可能与项目不完全兼容。为了解决上述问题，笔者参照其 SDK 实现了一个简洁版的 AliSmsSender ：仅包含短信发送功能，无需依赖阿里云的 SDK ，仅需要一个文件。 public class AliSmsSender { private static readonly HashSet<char> TextTable = new HashSet<char>("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_.~"); private static readonly HttpClient HttpClient = new HttpClient(); public AliSmsSender(string accessKeyId, string accessKeySecret, string signName) { if (string.IsNullOrWhiteSpace(accessKeyId)) { throw new ArgumentNullException(nameof(accessKeyId)); } if (string.IsNullOrWhiteSpace(accessKeySecret)) { throw new ArgumentNullException(nameof(accessKeySecret)); } if (string.IsNullOrWhiteSpace(signName)) { throw new ArgumentNullException(nameof(signName)); } AccessKeyId = accessKeyId; AccessKeySecret = accessKeySecret; SignName = signName; } public string AccessKeyId { get; } public string AccessKeySecret { get; } public string SignName { get; } public async Task<SendSmsResponse> SendAsync(string phone, string templateCode, object param) { var dictionary = new SortedDictionary<string, string>(StringComparer.Ordinal) { {"AccessKeyId", AccessKeyId}, {"Action", "SendSms"}, {"Format", "JSON"}, {"PhoneNumbers", phone}, {"SignatureMethod", "HMAC-SHA1"}, {"SignatureNonce", Guid.NewGuid().ToString()}, {"SignatureVersion", "1.0"}, {"SignName", SignName}, {"TemplateCode", templateCode}, {"TemplateParam", JsonConvert.SerializeObject(param)}, {"Timestamp", GetTimeStamp()}, {"Version", "2017-05-25"} }; var source = ComposeStringToSign("POST", dictionary); var value = SignString(source, AccessKeySecret + "&"); dictionary.Add("Signature", value); using (var request = new HttpRequestMessage( HttpMethod.Post, "http://dysmsapi.aliyuncs.com" ) { Content = new FormUrlEncodedContent(dictionary) } ) { using (var response = await HttpClient.SendAsync(request)) { var json = await response.Content.ReadAsStringAsync(); return JsonConvert.DeserializeObject<SendSmsResponse>(json); } } } private string SignString(string source, string accessSecret) { string result; using (var keyedHashAlgorithm = KeyedHashAlgorithm.Create("HMACSHA1")) { keyedHashAlgorithm.Key = Encoding.UTF8.GetBytes(accessSecret.ToCharArray()); result = Convert.ToBase64String( keyedHashAlgorithm.ComputeHash( Encoding.UTF8.GetBytes( source.ToCharArray() ) ) ); } return result; } private string ComposeStringToSign(string method, IEnumerable<KeyValuePair<string, string>> items) { var data = ComposeStringToSign(items); return $"{method}&{PercentEncode("/")}&{PercentEncode(data)}"; } private string ComposeStringToSign(IEnumerable<KeyValuePair<string, string>> items) { var builder = new StringBuilder(); foreach (var item in items) { builder.Append(PercentEncode(item.Key)) .Append('=') .Append(PercentEncode(item.Value)) .Append('&'); } if (builder.Length > 0) { builder.Length--; } return builder.ToString(); } private string GetTimeStamp() { return DateTime.UtcNow.ToString("yyyy-MM-ddTHH:mm:ssZ", DateTimeFormatInfo.InvariantInfo); } private string PercentEncode(string value) { var stringBuilder = new StringBuilder(); var bytes = Encoding.UTF8.GetBytes(value); foreach (var b in bytes) { var c = (char) b; if (TextTable.Contains(c)) { stringBuilder.Append(c); } else { stringBuilder.Append('%') .Append(string.Format(CultureInfo.InvariantCulture, "{0:X2}", (int) c)); } } return stringBuilder.ToString(); } public class SendSmsResponse { [JsonProperty("RequestId")] public string RequestId { get; set; } [JsonProperty("Message")] public string Message { get; set; } [JsonProperty("BizId")] public string BizId { get; set; } [JsonProperty("Code")] public string Code { get; set; } } }该实现依赖 Newtonsoft.Json 做 Json 反序列化，同时需要引入以下命名空间： using System; using System.Collections.Generic; using System.Globalization; using System.Net.Http; using System.Security.Cryptography; using System.Text; using System.Threading.Tasks; using Newtonsoft.Json;使用时，先用阿里云提供的访问密钥及签名信息构造 AliSmsSender 的实例，并调用其 SendAsync 方法即可： var sender = new AliSmsSender("accessKeyId", "accessKeySecret", "签名"); var result = await sender.SendAsync("13888888888", "模板Code", new { arg = "模板参数值" }); if (result.Code == "OK") { Console.WriteLine("发送成功"); } else { Console.WriteLine("发送失败：{0}", result.Code); }以上代码也可以在 GitHub 上获得，查看地址：https://gist.github.com/Soar360/18b9fea0ad08e5068e1e072ee4a21aa9

过去一段时间来, 众多的网站遭遇用户密码数据库泄露事件。层出不穷的类似事件对用户会造成巨大的影响，因为人们往往习惯在不同网站使用相同的密码，一家 “暴库”，全部遭殃。单向加密一个简单的方案是将明文密码做单向哈希后存储。单向哈希算法有一个特性，无法通过哈希后的摘要(digest) 恢复原始数据，这也是 “单向” 二字的来源，这一点和所有的加密算法都不同。常用的单向哈希算法包括 SHA-256, SHA-1, MD5 等。例如，对密码“passwordhunter” 进行 SHA-256 哈希后的摘要 (digest) 如下：“bbed833d2c7805c4bf039b140bec7e7452125a04efa9e0b296395a9b95c2d44c”可能是 “单向” 二字有误导性，也可能是上面那串数字唬人，不少人误以为这种方式很可靠， 其实不然。单向哈希有两个特性：1）从同一个密码进行单向哈希，得到的总是唯一确定的摘要2）计算速度快。随着技术进步，尤其是显卡在高性能计算中的普及，一秒钟能够完成数十亿次单向哈希计算结合上面两个特点，考虑到多数人所使用的密码为常见的组合，攻击者可以将所有密码的常见组合进行单向哈希，得到一个摘要组合, 然后与数据库中的摘要进行比对即可获得对应的密码。这个摘要组合也被称为 rainbow table（彩虹表）。更糟糕的是，一个攻击者只要建立上述的rainbow table，可以匹配所有的密码数据库。仍然等同于一家 “暴库”，全部遭殃。加盐哈希将明文密码混入 “随机因素 “，然后进行单向哈希后存储，也就是所谓的”Salted Hash（加盐哈希）”。这个方式相比上面的方案，最大的好处是针对每一个数据库中的密码，都需要建立一个完整的 rainbow table 进行匹配。 因为两个同样使用 “passwordhunter”作为密码的账户，在数据库中存储的摘要完全不同。在 C# 中实现加盐哈希早在2016年，MD5 作为哈希算法已经不可靠，可以人为制造碰撞，于是本文采用了 SHA256 作为哈希算法。同时在哈希前生成了一个 Guid 作为盐和哈希值拼接在一起： using System; using System.Security.Cryptography; using System.Text; public class PasswordHasher { public string HashPassword(string password) { var rnd = Guid.NewGuid().ToString("N").Substring(10); return BuildHash(rnd, password); } public bool CheckPassword(string password, string hash) { if (string.IsNullOrWhiteSpace(hash)) { return false; } var items = hash.Split('|'); if (items.Length != 2) { return false; } var rnd = items[0]; return hash == BuildHash(rnd, password); } private string BuildHash(string rnd, string password) { var key = rnd + "|" + password.Trim(); var hash = Hash(key); return rnd + "|" + hash; } private string Hash(string input) { using (var sha = new SHA256CryptoServiceProvider()) { var bytes = Encoding.UTF8.GetBytes(input); bytes = sha.ComputeHash(bytes); return Convert.ToBase64String(bytes); } } }生成加盐哈希值： //生成加盐哈希 var hasher = new PasswordHasher(); var pwd = hasher.HashPassword("123456"); Console.WriteLine("加盐哈希值为：{0}",pwd);校验密码是否匹配： //校验密码是否匹配 var hasher = new PasswordHasher(); var hash = "89455bb276f037799fea1d|1rcfw+tSKhpG7zuW7Sm6SuMgjafAwsMg76OlyFkXLm8="; var pwd = "123456"; if (hasher.CheckPassword(pwd, hash)) { Console.WriteLine("密码正确"); } else { Console.WriteLine("密码不匹配"); }