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

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

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

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

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

—— 2015年,于家中

© owlman all right reserved,powered by Gitbook该文件修订时间: 2019-09-25 13:47:45

results matching ""

    No results matching ""