《元素模式》译后记：回答一些问题

这本书译完至今已经快两年了，电子工业出版社在2014年7月正式出版了它。在此之后，我从审稿者以及读者手里得到的大部分反馈无非就是三个问题：为什么书名翻译成"元素模式"？这本书与《设计模式》这本书的关系是什么？这些模式有什么用？所以，我打算写一篇文章，谈谈我的看法。

首先，这本《Elemental Design Patterns》的书名，如果按照中规中矩的译法应该翻译成"设计模式要素"，但看完全书，你会遇到一个问题，就是这本书讲的是16 种可用各种编程语言实现的模式。换句话说，它是有实体的"模式"，而不是抽象的"要素"。所以似乎改成"元素级设计模式"更为合适。但作为一个学术性的，得了Jolt大奖的作品，用如此之长的书名有点不太合适。因此本书的第一译者高博兄与我反复讨论，最终定了这四个字的书名。我们希望它能激发起读者好奇心，并且让读者读完之后才能理解"元素"这两个字的精妙所在。

接下来，我来说说它与GoF模式之间的关系。其实，关系就在"元素"这两个字上，元素在化学上对应的是原子，原子通常意味着不可再分性（当然，实际上还可以再分的，这里只是一个比喻）。作者在书中构建了一个设计空间，按照OOP中最简单的设计概念分成了几个不同的设计空间。然后用这种空间维度对现有的设计模式，主要就是GoF模式进行了分解。所以从粒度上来看，元素模式最重要的是其原子性，它被作者认为是不可再分的模式，而后者则是由元素模式组成的分子模式或者更大粒度的模式。这种思想在这本书中是至关重要的。

最后再来谈谈"有什么用"的问题。通常我们提到单件、工厂这些模式的时候，很容易有意无意的把模式认识成模版，来生搬硬套，但如果我们把这些模式分解成元素模式，就很容易理解到它不过是一些设计套路的组合而已，而这种套路才是"模式"，它们是可以变化的，根据实际情况重新组合的，甚至还是可以作为反例的。它们并不是设计社区所流传的神话，后来者只能把它们供起来，生搬硬套。因此。模式的粒度越小，我们组合起来的灵活度就越高。当然了，和这个现实世界一样，你不知道原子的存在，物质也是这样组成的，这些模式你其实天天在用，只不过你是不是"有意识"的在用而已。这是一个设计经验的问题，比如java里面本身就用了很多工厂模式，但如果你没有意识到他是工厂模式，他可能就只是用来创建标准库的对象，一旦你自定义对象就不会追求这种创建方式的一致性，这样一来，后期维护的时候，由于你自己的库，和标准库之间有明显的设计差异，这会带来各种各样的问题。比如C++中，几乎一个库一种string类型就是一个典型的例子。元素模式的作用也是如此。

—— 2015年，于家中