《元素模式》譯後記

這本書譯完至今已經有大半年了，電子工業出版社也在去年的九月正式出版了它。在此之後，我從審稿者以及讀者手裡得到的大部分反饋無非就是三個問題：為什麼書名翻譯成“元素模式”？這本書與《設計模式》這本書的關係是什麼？這些模式有什麼用？所以，我打算寫一篇文章，談談我的看法。

首先，這本《Elemental Design Patterns》的書名，如果按照中規中矩的譯法應該翻譯成“設計模式要素”，但看完全書，你會遇到一個問題，就是這本書講的是16種可用各種程式語言實現的模式。換句話說，它是有實體的“模式”，而不是抽象的“要素”。所以似乎改成“元素級設計模式”更為合適。但作為一個學術性的，得了Jolt大獎的作品，用如此之長的書名有點不太合適。因此本書的第一譯者高博兄與我反覆討論，最終定了這四個字的書名。我們希望它能激發起讀者好奇心，並且讓讀者讀完之後才能理解“元素”這兩個字的精妙所在。

接下來，我來說說它與GoF模式之間的關係。其實，關係就在“元素”這兩個字上，元素在化學上對應的是原子，原子通常意味著不可再分性（當然，實際上還可以再分的，這裡只是一個比喻）。作者在書中構建了一個設計空間，按照OOP中最簡單的設計概念分成了幾個不同的設計空間。然後用這種空間維度對現有的設計模式，主要就是GoF模式進行了分解。所以從粒度上來看，元素模式最重要的是其原子性，它被作者認為是不可再分的模式，而後者則是由元素模式組成的分子模式或者更大粒度的模式。這種思想在這本書中是至關重要的。

最後再來談談“有什麼用”的問題。通常我們提到單件、工廠這些模式的時候，很容易有意無意的把模式認識成模版，來生搬硬套，但如果我們把這些模式分解成元素模式，就很容易理解到它不過是一些設計套路的組合而已，而這種套路才是“模式”，它們是可以變化的，根據實際情況重新組合的，甚至還是可以作為反例的。它們並不是設計社群所流傳的神話，後來者只能把它們供起來，生搬硬套。因此。模式的粒度越小，我們組合起來的靈活度就越高。當然了，和這個現實世界一樣，你不知道原子的存在，物質也是這樣組成的，這些模式你其實天天在用，只不過你是不是“有意識”的在用而已。這是一個設計經驗的問題，比如java裡面本身就用了很多工廠模式，但如果你沒有意識到他是工廠模式，他可能就只是用來建立標準庫的物件，一旦你自定義物件就不會追求這種建立方式的一致性，這樣一來，後期維護的時候，由於你自己的庫，和標準庫之間有明顯的設計差異，這會帶來各種各樣的問題。比如C++中，幾乎一個庫一種string型別就是一個典型的例子。元素模式的作用也是如此。