書摘《Implementation Patterns》

這本書在書單中很久了，前陣子有空繞去天龍書局發現有中譯版就買回家來翻翻 (沒錯，買中譯版 XD)，一看很合胃口，很快就翻完了，心有戚戚焉的句子很多，特別是在最後一章關於框架設計的部分。

第三章提到三個價值觀：溝通、簡單和靈活，這也是我目前在設計與撰寫程式時考慮的優先順序，我在意的是我寫的這一段程式其他人是否容易看懂？不會刻意去用一些語法讓程式變短，事實上我自己認為讓程式變短不一定讓程式好懂：

程式應該讀起來像一本書一樣。它需要有情節和韻律，句子間應該有優雅的、小小的高低起伏。

所以我在想 Swift 的 method 和參數名稱時，介係詞用的蠻多的，就是希望能讀起來像一般的句子。靈活是放在最後，甚至現在很少想太多了，讓程式簡單好懂先能動，單元測試能過，若遇到真的要改既有的程式時，才開始想怎麼重構讓它變靈活，但也不是什麼都不想，如果知道在不久的未來一定會做的東西，還是會事先規劃一些彈性。

「簡單性和大規模測試所帶來的靈活性」比「專門設計出來的靈活性」更為有效

第五章中提到的很多概念，其實多年研究 Java 的 API 後，自然變成自己的習慣，像是什麼時候用抽象介面，什麼時候用抽象類別，又什麼時候用有版本的介面，那些 method 適合放到 library class，但看過第五章後又有更深的體會了。

Implementation pattern 其實都講些很小的東西，大多是寫程式時，時時要做決定的那種層級的 pattern，像是 delegate 該用什麼方法放入，就有不同的思維，真的很有趣。

將控制流的小片段歸類，讓不想深究的閱讀者先得到一個「抽象的理解」，同時又為需要深入領會的閱讀者提供「更詳盡的細節」。

這大概也是我設計 method 或是將一大段程式切割成數個 method 的原則，並盡量保持 method 顆粒度的一致性的原因了。

它可以告訴閱讀者這段計算的目的何在，讓閱讀者免受實作的影響。閱讀者通常只憑閱讀方法的名稱，就可以一眼分辨出哪些是自己要找的功能。

意圖比實作細節重要，少了意圖，幫忙 code review 的人其實也很辛苦，因為要從實作去猜意圖，但就可能少想到一些該 review 的東西。

呼叫方法是在講述一個故事，好的方法名稱會讓故樹講述得更流暢。

跟我共事過的 Java 工程師可能都知道我不喜歡用 Lombok 這類工具，即便是 getter 和 setter，誰說一定要有，就算有，也不一定是 public，甚至，我還會用 immutable interface 將 getter 和 setter 拆開。

更謹慎地暴露方法，從最嚴格的可見性開始，有必要時才暴露。

書中也提到了我個人很喜歡轉換方法及轉換建構函式，以及一點我個人在看一些目前 Java 第三方套件很愛使用的 builder 時，一直不解的問題：

透過提供無參數的建構函式和一系列 setting方法來建立物件。可以滿足靈活性的要求。不過這種方法無法表達出「物件需要傭有哪些參數組合才能正常運作」。

即便參數可能有點多，要 overloading 多個可省略參數的版本，但我還是偏好建構子，只有特定理由才會使用工廠方法：

工廠方法可以回傳更抽象的類型 (某個子類型或介面的某個實作)，還可以根據方法的意圖來命名，不必與類別名稱一致。不過「工廠方法」也增加了複雜性，因為只有在能發揮它們的優勢時，才應該使用「工廠方法」，而不要把「工廠方法」看作是理所當然。

多年前曾在 C.C. Agile 分享過關於重構的一些想法，我還記得那時提到自己寫的 Comic Surfer 有提供 SDK 給第三方寫新的 plug-in，文件建議請繼承 SDK 提供的 abstract class 而不是實作 interface，那時我也是自己思考出來這個方法，因為即使後來 interface 有新增函式，只要在 abstract class 加入合乎邏輯的預設實作，第三方的 plug-in 在不修改程式的情況下，仍然可以在新版本中使用。

框架開發所面臨的挑戰：如何減少不相容的更新所帶來的影響；如何在設計框架時，避免不相容的更新。想要在改進框架時，把對客戶程式碼的影響降到最低，會給框架帶來額外的複雜度，同時需要向客戶隱藏一些特性，而且在做必要的修改時，必須認真仔細地對修改之處進行溝通。

有過這經驗後，一些想法也回到日常的開發中，即便這東西沒有給第三方使用，我依然會想到「責任」與「相容性」問題，這反而讓程式的邊界更清晰，也更好維護。很有意思也很值得推薦的一本書。

Apr 9, 2018