面向数据编程 Data-Oriented Programming [2]

0.2.3 原则#1的好处

  当我们小心翼翼地将代码与数据分开时，我们的程序就会受益：

1. 代码可以在不同的环境下重复使用
2. 代码可以单独测试
3. 系统趋于不那么复杂

好处#1：代码可以在不同的环境中重复使用
  想象一下，在我们的程序中，除了作者实体之外，还有一个与作者无关的用户实体，但在名字和姓氏方面，它有与作者实体相同的数据字段：firstName和lastName字段。
  作者和用户计算全名的逻辑是相同的。但是，在有createAuthorObject的版本中，不能直接重用代码。
  当代码和数据混合时，实现代码重用的一个方法是使用OO机制，如继承或组合，让用户和作者对象使用同一个全名方法。在一个简单的用例中，这可能很好，但在现实世界的系统中，大量的类（无论是基类还是复合类）往往会增加我们系统的复杂性。
  另一种方法在清单0.5中显示：我们将fullName的代码复制到一个创建用户对象（createUserobject）函数中。

清单 0.5 在OO中重复代码以避免继承

function createAuthorObject(firstName, lastName, books) {
	var data = {
		firstName: firstName,
		lastName: lastName,
		books: books
	};

	return {
		fullName: function fullName() {
			return data.firstName + " " + data.lastName;
		}
	};
}

function createUserObject(firstName, lastName, email) {
	var data = {
		firstName: firstName,
		lastName: lastName,
		username: username
	};

	return {
		fullName: function fullName() {
			return data.firstName + " " + data.lastName;
		}
	};
}

var obj = createUserObject("John", "Doe", "john@doe.com");
obj.fullName();

  在DO版本中，createAuthorData和fullName是分开的，不需要对现有的代码（处理作者的代码）进行修改，以使其对用户实体可用。我们只是利用了一个事实，即与用户和作者的全名计算有关的数据遵循相同的形状，我们在用户数据上调用fullName。
  在没有修改的情况下，fullName函数在作者数据和用户数据上都能正常工作，如清单0.6所示。

清单0.6 在不同类型的数据实体上使用相同的代码（FP风格）。

function createAuthorData(firstName, lastName, books) {
	return {
		firstName: firstName,
		lastName: lastName,
		books: books
	};
}

function fullName(data) {
	return data.firstName + " " + data.lastName;
}

function createUserData(firstName, lastName, email) {
	return {
		firstName: firstName,
		lastName: lastName,
		email: email
	};
}

var authorData = createAuthorData("Isaac", "Asimov", 500);
fullName(authorData);

var userData = createUserData("John", "Doe", "john@doe.com");
fullName(userData);

  当原则1被应用于OO中时，我们可以以直接的方式重用代码，即使我们使用类。在静态类型的OO语言（如Java或C#）中，我们必须为AuthorData和UserData创建一个共同的接口，但在动态类型的语言（如JavaScript）中，这不是必需的。
  NameCalculation.fullName()的代码对作者数据和用户数据都有效，如清单0.7所示。

清单0.7 在不同类型的数据实体上使用相同的代码（OOP风格）。

class AuthorData {
	constructor(firstName, lastName, books) {
		this.firstName = firstName;
		this.lastName = lastName;
		this.books = books;
	}
}

class NameCalculation {
	static fullName() {
		return data.firstName + " " + data.lastName;
	}
}

class UserData {
	constructor(firstName, lastName, email) {
		this.firstName = firstName;
		this.lastName = lastName;
		this.email = email;
	}
}

var userData = new UserData("John", "Doe", "john@doe.com");
NameCalculation.fullName(userData);

var authorData = new AuthorData("Isaac", "Asimov", 500);
NameCalculation.fullName(authorData);

TIP 当我们把代码和数据分开时，就可以直接在不同的情况下重复使用代码。不同的环境中重用代码。这种好处在FP和OOP中都是可以实现的。

好处#2：代码可以被隔离起来测试
  将代码与数据分离的另一个好处是，我们可以在一个孤立的环境中自由地测试代码，这与前一个好处类似。
  当我们不把代码和数据分开时，我们就不得不实例化一个对象，以测试其每个方法。它的每个方法。例如，为了测试存在于 createAuthorObject函数中的全名代码，我们需要实例化一个作者对象，如清单0.8所示

清单0.8 当代码和数据混合时测试代码需要实例化完整的对象

var author =  createAuthorObject("Isaac", "Asimov", 500);

author.fullName() === "Isaac Asimov"

  在这种简单的情况下，这并不是什么大麻烦（只是不必要地加载了isProlific的代码），但在现实世界中，实例化一个对象可能会涉及很多不必要的步骤。
  在DO版本中，createAuthorData和fullName是分开的，我们可以自由地创建要传递给fullName的数据，并孤立地测试fullName。清单0.9中显示了一个例子。

清单 0.9 将代码与数据分离，使我们能够在一个孤立的环境中测试代码（FP风格）。

fullName({firstName: "Isaac", lastName: "Asimov"}) === "Isaac Asimov"

  如果我们选择使用类，我们只需要实例化一个数据对象。如清单0.10所示，isProlific的代码住在一个比fullName单独的类中，不必为了测试fullName而加载。

清单 0.10 将代码与数据分离，使我们能够在一个孤立的环境中测试代码（OOP风格）。

var data =  new AuthorData("Isaac", "Asimov");

NameCalculation.fullName(data) === "Isaac Asimov"

TIP 当我们把代码和数据分开时，写测试就更容易了

好处3：系统往往不那么复杂
  应用原则#1的第三个也是最后一个好处是，系统往往不那么复杂。这个好处是最深刻的，但也是最难以解释的。
  我所指的复杂性类型是使系统难以理解的类型，它在 Out of the Tar Pit 这篇美丽的论文中被定义。它与一个程序所消耗的资源的复杂性没有关系。
  同样，当我们提到简单性时，我们的意思是 “不复杂”，换句话说：容易理解。
  请记住，复杂性和简单性（就像难和易）不是绝对的，而是相对的概念。我们可以比较两个系统的复杂性，认为系统A比系统B更复杂（或更简单）。

NOTE 在本书中，复杂意味着：难以理解

  当代码和数据驻留在不同的实体中时，系统往往更容易理解，原因有二。

1. 数据实体或代码实体的范围要比结合了代码和数据的实体的范围小。因此，每个实体都更容易理解。
2. 系统的实体被分成不相干的组：代码和数据。因此，实体与其他实体的关系较少

  让我在一个图书馆管理系统的类图上说明这一见解，如图0.2所示在这里，代码和数据是混合的。

图0.2 图书馆管理系统的类图概述

 
  你不需要知道这个系统的类的细节，就可以知道这个图代表了一个复杂的系统，即它很难理解。这个系统之所以难以理解，是因为组成这个系统的实体之间存在着许多依赖关系。
  系统中最复杂的实体是图书管理员实体，它通过7种关系与其他实体相连。一些关系是数据关系（关联和组合），一些关系是代码关系（继承和依赖）。但是在这个设计中，图书管理员实体混合了代码和数据，因此它必须同时参与数据和代码关系。
  现在，如果我们把系统的每个实体分成一个代码实体和一个数据实体，而不对系统做任何进一步的修改，我们就会得到图0.3所示的图，它是由两个不相连的部分组成的。

• 左边部分只由数据实体和数据关系组成：关联和组合
• 右边部分仅由代码实体和代码关系组成：依赖和继承

图0.3 一个类图，每个类都被分成了代码和数据实体

 
  代码和数据分开的新系统比原来代码和数据混合的系统更容易理解：我们可以自由地理解系统的数据部分，也可以自由地理解系统的代码部分。

TIP 由不相连的部件组成的系统比由单个部件组成的系统要简单。

  有人可以说，代码和数据混合在一起的原始系统的复杂性是由于糟糕的设计，一个有经验的OO开发者会设计一个更简单的系统，利用智能设计模式。这倒是真的，但从某种意义上说，这并不重要。原则#1的重点是，由不结合代码和数据的实体组成的系统往往比由结合代码和数据的实体组成的系统更简单。
  有人说过很多次，简单才是硬道理。根据DO的第一原则。当我们把代码和数据分开时，简单性更容易实现。

TIP 当我们把代码和数据分开时，简单性更容易实现。