unity尧明的博客

英文原文：https://blog.molecular-matters.com/2011/11/03/adventures-in-data-oriented-design-part-1-mesh-data-3/  让我们面对现实吧，现代处理器(无论是个人电脑、游戏机还是手机)的性能主要取决于内存访问模式。尽管如此，面向数据的设计被认为是新奇的东西，只会慢慢进入程序员的大脑，这一点确实需要改变。让同事修复您的代码并提高其性能从一开始就不能成为编写糟糕代码的借口(从性能的角度来看)。  这篇文章是正在进行

英文原文：https://rohiton.wordpress.com/2016/06/28/persistent-data-structures/  函数式编程鼓励不变性，一些非常纯粹的函数式编程语言(如Haskell)甚至根本不支持可变性。持久化数据结构是纯函数编程的关键，它有助于实现不变性，同时保持性能。  大多数第一次使用函数式编程的开发人员认为，如果数据结构是不变的，更新数据结构会造成大量复制，并造成大量GC/内存压力-这是不正确的。所有好的函数式编程语言都支持所谓的开箱即用的持久数据结构。

6 单元测试和面向数据的编程之间的协同作用6.1 简介  在面向数据的系统中，我们的代码主要是处理数据操作：我们在第一部分写的大多数函数都是接收数据和返回数据。因此，编写单元测试来检查我们的代码是否符合我们的期望是很容易的。一个单元测试是由产生数据输入的测试用例组成，并将函数的数据输出与预期的数据输出进行比较。  在这一章中，我们为我们在第一部分中写的查询和突变写单元测试。本章内容包括。为一个测试案例生成最小的数据输入一个函数的输出与预期输出的比较关于测试案例的质量和数量的指导意见6.2

5.6 同时发生的突变之间的调解实例你：你能给我举个例子，说明不冲突的并发突变之间的调解吗？乔：当然，让我们从一个没有用户的图书馆和一个只有一本书的目录开始。Watchmen，如清单5.5所示。清单5.5 一个小型图书馆的数据var library = { "name": "The smallest library on earth", "address": "Here and now", "catalog": { "booksByIsbn": {

5.4 调解算法的实现你：为了实现调解算法，需要对代码做什么样的修改？乔：它只需要修改SystemData.commit()的代码，如清单5.1所示。清单5.1 系统数据类class SystemData { systemData; get() { return this.systemData; } set(_systemData) { this.systemData = _systemData; } comm

高度可扩展的并发控制5.1 简介  在上一章中，我们已经说明了状态管理的多版本方法，其中突变被分成两个不同的阶段：只处理计算的计算阶段和向前移动状态引用的提交阶段。  通常，在生产系统中，突变同时发生。像我们在上一章中所做的那样天真地推进状态是不合适的。在本章中，我们将学习如何处理并发突变。  在DO中，只有提交阶段的代码是有状态的，这一事实允许我们利用不涉及任何锁定机制的乐观并发控制策略。因此，读写吞吐量很高。  对代码的修改不是微不足道的，因为我们必须实现一个协调并发突变之间的算法。但是修改只

4.6 确保系统状态完整性你：函数在计算阶段处理不变数据的方式仍然困扰着我：我们如何保持数据完整性？乔：你是什么意思？你：在面向对象中，数据只由与数据属于同一类的方法操作。它可以防止其他类损坏类的内部状态。乔：你能给我举一个图书馆失效的例子吗？你：例如，假设突变的代码将一个图书项目添加到成员的图书借阅中，而没有在catalog中将该图书项目标记为已借出。那么系统数据就会被破坏。乔：在DO中，我们有权确保整个系统级别的数据完整性，而不是将验证分散在许多类中。你：我不明白。乔：提交阶段的代码对于

4.4 数据安全你：关于结构性分享的事情，我有些不清楚。如果我们编写代码来修改在两个版本的数据之间共享的数据部分，会发生什么情况？更改是否会影响两个版本？乔：你能不能写一段代码来说明你的问题？你开始在笔记本电脑上键入内容，然后就会出现清单4.4中的代码片段，它说明了你的观点。清单4.4 修改两个版本之间共享的数据的一段代码var member = { "email": "joe@me.com", "password": "secret", "isBlocked": true}var

4.3 结构共享正如我们在上一节中提到的，结构化共享允许高效地创建不可变数据的新版本。在DO中，我们在变异的计算阶段利用结构共享来基于系统的当前状态来计算系统的下一个状态。在计算阶段，我们不必处理状态管理：这会延迟到提交阶段。因此，变异计算阶段涉及的代码是无状态的，与查询代码一样简单。你：我真的对这种创建新版本数据的高效方式很感兴趣。它怎麽工作?乔：让我们从我们的图书馆系统举一个简单的例子。假设您想要修改目录中某本书中某个字段的值，例如“守望者”的出版年份。你能告诉我守望者出版年的信息路径是什么吗

具有不可变数据的状态管理4.1 介绍

3.6 处理不同类型的record  我们已经了解了DO如何使我们能够将record作为一等公民对待，可以使用泛型函数以灵活的方式对其进行操作。但是，如果record只不过是字段的聚合，我们如何知道记录的类型呢？DO对这个问题有一个令人惊讶的答案。你：我有一个问题。如果一条record只不过是一张Map，你怎么知道记录的类型呢？乔：这是一个很好的问题，答案也很令人惊讶。你：我很好奇。乔：大多数时候，没有必要知道record的类型。你：什么意思？乔：我的意思是，最重要的是字段的价值。例如，查看

3.4 使用泛型函数操作数据乔：现在，让我向你展示我们是如何利用泛型函数来操作数据的。你：好，我很好奇你将如何实现图书馆管理系统的搜索功能。乔：好的。首先，根据图3.3中的数据模型，让我们实例化一个图书馆目录数据的Catalog record，我们只有一本书“守望者”：清单 3.5 Catalog recordvar catalogData = { "booksByIsbn": { "978-1779501127": { "isbn": "978-1779501127",

3.3 将records表示为Maps  到目前为止，我们已经从高系统级别说明了从代码和数据分离中获得的好处。代码和数据之间存在分离的关注点，并且每个部分都有明确的约束：代码由将数据作为显式参数接收的静态函数组成将数据实体建模为records，records之间的关系用集合和索引表示现在出现了数据表示形式的问题  虽然DO对集合和索引没有什么特别的看法，但它对records的表示非常固执己见。它适用于每种编程语言，无论是动态类型的还是静态类型的，面向对象的还是函数式的，这都无关紧要。在DO中，

使用泛型函数操作整个系统的数据3.1 简介  现在我们已经将代码从数据中分离出来，让我们来讨论一下数据本身。  给定一个设计为OO中严格的类层次结构的系统数据模型，DO规定我们将数据模型表示为Map和集合的灵活组合，其中我们可以通过信息路径访问每条信息。  本章深入探讨了DO原则#2：NOTE 用通用数据结构表示数据实体  当我们将记录表示为字符串映射而不是从类实例化的对象时，我们提高了系统灵活性。这将数据从基于类的系统的僵化中解放出来。数据成为一等公民，具有添加、删除或重命名字段的通用功能

2.5 DO系统易于理解  您可以查看代表系统高级设计的两个图：图2.7中的数据思维导图中的数据实体图2.8模块图中的代码模块有点困惑，你问乔：你：我不确定这个系统是否比传统的OO系统好，在传统的OO系统中，对象封装数据。乔：与传统的OO系统相比，DO系统的主要好处是更容易理解。你：是什么让它更容易理解？乔：系统清晰地划分为代码模块和数据实体。你：我不明白你的意思。乔：当您尝试理解系统的数据实体时，您不必考虑操作数据实体的代码的细节。你：你的意思是，当我看着我的图书馆管理系统的数据

2.4 代码模块  DO设计过程的第二步是定义系统的代码模块。乔：既然您已经确定了系统的数据实体，并将它们分组到高级组中，那么是时候考虑一下系统的代码部分了。你：你说的代码部分是什么意思？乔：考虑这个问题的一种方式是确定你的系统的功能。你将再次查看Nancy的需求餐巾纸，这一次您将突出显示代表系统功能的动词短语：旁白突出显示需求中与功能相对应的术语两类用户：管理员和会员用户通过电子邮件和密码登录系统。会员可以借书会员和图书管理员可以按书名或作者搜索图书图书馆员可以屏蔽和解锁会员(

通过将代码与数据分离来降低系统复杂性2.1简介  正如我们在第0章中提到的，面向数据编程(DO)的最大洞察力在于，我们可以通过将代码与数据分开来降低系统的复杂性。事实上，当代码与数据分离时，我们的系统由两个可以分开考虑的主要部分组成：数据实体和代码模块。  本章深入探讨了面向数据编程的第一个原则：NOTE 原则#1：以代码驻留在函数中的方式将代码与数据分开，这些函数的行为不依赖于以某种方式封装在函数上下文中的数据。  我们在第1章介绍的图书馆管理系统的上下文中说明了代码和数据的分离，并揭示了这

1.7 当代码锁定在类中时，类层次结构很复杂  避免在OO中两次编写相同代码的一种方法涉及类继承。实际上，当预先知道系统的每个需求时，您可以这样设计类层次结构，即具有共同行为的类从基类派生。...

1.5当对象可变时，理解代码需要额外的思考  在完成我们在上一节中介绍的系统级分析之后，您可能会有点累。  让我们刷新一下，看看一些代码。  请看一下清单1.1所示的代码：我们获得一个成员的阻塞状态，并将其显示两次。  如果我告诉您，当我调用displayBlockedStatusTwice时，程序在第一次console.log()调用中显示为true，您能告诉我程序在第二次console.log()调用中显示了什么吗？清单1.1非常简单的代码class Member { isBlock

1.3 复杂性来源  在您开始编写代码之前，当您为自己准备另一杯咖啡时，我想挑战一下您的设计。它在纸上可能看起来漂亮而清晰，但我要说这个设计太复杂了。  这不是因为您选择了错误的类，也不是因为您误解了类之间的关系。它要深得多。这是关于您选择实现系统的编程范例。它是关于面向对象范例的。它是关于面向对象的趋势会增加系统的复杂性。TIP OO有创建复杂系统的趋势。  正如我们在第0章中提到的，我所指的复杂性类型使系统变得难以理解，因为它在美丽的论文Out of the Tar Pit中有定义。它与程序

1.2.4 解释类图的每一部分戴夫：“谢谢你给我上这个简短的UML课程。现在我明白你图中每种箭头的意思了。”你：“我的荣幸。”戴夫：我应该先看什么类？你：我想你应该从Library开始。图书馆类Library是这个系统的根类 图1.6 Library类   就代码而言，Library对象本身不做任何事情，它将一切委托给它拥有的对象。  就数据而言，Library象拥有：多个Member对象多个Librarian对象一个Catalog对象Librarian, Me

面向对象的发展趋势编程朝着增加系统复杂性的方向发展1.1导言  在本章中，我们探讨了面向对象系统的复杂化趋势。  这种复杂性与特定面向对象语言的语法或语义无关。程序应该由包含某些状态的对象以及用于访问和操作该状态的方法组成，这是OO基本洞察力所固有的东西。  在本章中，我们将说明面向对象的一些基本方面是如何增加系统的复杂性的。  多年来，面向对象生态系统通过向语言添加新功能(例如匿名类和匿名函数)，以及通过向开发人员提供更简单的接口(例如Java中的Spring和Jackson)来开发隐藏部分复

0.4 DO原则#3：数据是不可变的0.4.1原理简述  我们现在处于这样一个阶段：我们的数据与我们的代码分离，我们的数据用通用数据结构表示。现在是管理数据变化的问题。  DO对此非常严格，不允许对数据进行任何改变。NOTE 原则#3：数据是不可改变的。  在DO中，我们通过创建新版本的数据来管理数据的变化。  另外，我们允许改变一个变量的引用，使其指向一个新的数据版本。决不能改变的是数据本身的值。0.4.2 原则#3的说明  想一想42这个数字。当你在42上加1时，会发生什么？它会变成

0.3 DO原则#2：用通用数据结构表示数据实体0.3.1原理简述  当我们坚持原则#1的时候，代码与数据是分开的。DO对组织代码所使用的编程结构没有意见，但它对数据应该如何表示有很多意见。这就是原则#2的主题。NOTE 原则2：用通用数据结构表示你的应用程序的数据结构。  最常见的通用数据结构是Map(字典)和数组。但是，使用其他的通用数据结构也是完全可以的（例如，集合、列表、队列…)  原则#2不涉及数据的可变性或不可变性。这就是原则3的主题：数据是不可改变的。0.3.2 原则#2的说明

0.2.4 原则#1的代价  世上没有免费的午餐。使用原则#1是有代价的。  为了从代码和数据之间的分离中获益，我们必须付出的代价是：对什么代码访问什么数据没有控制没有包装我们的系统是由更多的实体组成的代价#1：无法控制什么代码访问什么数据  当代码和数据混合在一起时，人们可以很容易地理解哪些是访问某种数据的代码片断。  例如，在OO中，数据被封装在一个对象中。它保证了数据只能被对象的方法所访问。  在DO中，数据是自成一体的。如果你愿意，它是透明的。因此，它可以被任何一段代码所访问。

0.2.3 原则#1的好处  当我们小心翼翼地将代码与数据分开时，我们的程序就会受益：代码可以在不同的环境下重复使用代码可以单独测试系统趋于不那么复杂好处#1：代码可以在不同的环境中重复使用  想象一下，在我们的程序中，除了作者实体之外，还有一个与作者无关的用户实体，但在名字和姓氏方面，它有与作者实体相同的数据字段：firstName和lastName字段。  作者和用户计算全名的逻辑是相同的。但是，在有createAuthorObject的版本中，不能直接重用代码。  当代码和数据混合

面向数据的编程原则0.1 简介