寫給你們看的設計書——讀後筆記

     《寫給你們看的設計書》介紹了設計的四個基本原則：親密性、對齊、重複、對比。做爲一個軟件「設計師」，我也來聊聊讀過這本書以後，我對這四個原則的一點理解。

親密性

        親密性原則是指：內涵相關聯的內容，在結構、關係上也應保持關聯。
        以軟件設計的角度來講，一項業務所包含的功能、一個功能所包含的代碼，應該在結構、關係上保持關聯。例如把這些代碼放到同一個包下、用同一套規則來命名。這樣，當咱們須要查閱、修改這個功能，須要處理哪些代碼就「一望而知」了。
        很明顯，「親密性」實際上就是軟件工程中常說的「高內聚」。「高內聚」之於軟件工程，就如空氣之於人同樣：重要，卻經常被忽視。最多見的一種忽視「高內聚」原則而產生的bad smell，就是不經過繼承或組合的方式來新增業務邏輯，而是在原有代碼中用if-else/switch-case等方式來擴展。這樣一來，新功能的代碼就沒法放到新功能的「羣組」內，進而，在查閱、修改新功能的代碼時，沒法「一望而知」工做範圍、也沒法「一望而知」風險範圍。
        固然，上面的bad smell也能夠說是違反了「低耦合」原則致使的。可是必須認可，違反了「高內聚」，則必定會違反「低耦合」。例如，操做Ecxel文件的Service類，卻把POI組件泄露到接口以外——這是Excel操做代碼不夠內聚的緣故；這同時也致使了調用方與POI組件發生耦合，從而違反「低耦合」原則。
        「低耦合」能夠稱爲「私密性」原則，不過《寫給你們看的設計書》中沒有相關論述。這大概是由於，其它領域內的設計是爲了充分表達本身的設計目標——要「一望而知」。而軟件設計不只要「一望而知」，還要「一望僅知」。只有這樣，才能充分地拆分和管理複雜度。

對齊

        「一望而知」各組件的內涵及範圍，是「親密性」原則的優勢；而「一望而知」各組件之間的結構、關係，這是「對齊」原則帶來的好處。標題對齊，「一望而知」全篇有幾個標題；段落對齊，「一望而知」這個標題下有多少個段落。軟件設計中會有這樣的好事嗎？
        我有一個很切身的體會，也是一個很好的例子：文件後綴命名。例如，某個接口類命名爲AlphaService，那麼它的全部子類都在接口名後面綴上說明性單詞，以此構成本身的名字。如命名爲AlphaServiceAsChain、AlphaServiceAsDispatcher、AlphaService4English、AlphaService4Chinense，諸如此類。這樣，因爲IDE和操做系統的文件系統、查詢功能默認都是字母順序排列，於是這一系列類在「展現」上就很是緊湊——這就使得它們的關係「一望而知」。
        「對齊」規則對如今的軟件設計有很大的借鑑意義；規則若是執行得好，軟件設計將會獲益匪淺。這是由於，現代軟件內部的邏輯複雜度通常都很是高。咱們要經過設計來下降複雜度，通常只有一種辦法：代碼功能簡單，而關係複雜。上面例子中提到的「接口-實現類」就是一種代碼關係，而這種關係能夠「一望而知」，這就是「對齊」原則給系統的裨益。
        固然，軟件中「對齊」的方式還有不少。略牽強一點來說，同一個接口下的實現類都是向接口「對齊」；同一個模板類下的子類都是向模板「對齊」；符合里氏替換原則的都算「對齊」；等等。

重複

        「重複」對其它領域的設計工做來講，也許確實是很是重要的一項原則。運用這項原則，能夠把設計意圖更加有效地表達出來。
        可是，重複無疑是咱們軟件開發和設計人員最痛恨的：Don't Repeat Yourself! DON'T!!
        也許這是軟件設計與其它領域設計的一個不一樣之處。軟件設計不只要考慮表達設計意圖，還要管理系統複雜度。「一望僅知」是一種方式，DRY也是一樣的考慮。

對比

      設計中進行「對比」，通常是爲了突出核心設計目的。對軟件設計來講，「對比」原則參考意義不大。

後記

      最近的技術思考和積累，關注點都不在代碼或系統的細節上，而是轉向了一些業務系統或邏輯的設計上。這跟個人技術價值觀有關：技術的價值是須要體如今業務系統中的。不過這能夠另外展開，這裏打住。
      「設計」行業由來已久，建築設計、時裝設計、包裝設計、城市規劃設計、工業設計、平面設計……等等等等。這些設計門類都已經積累了不少經驗，軟件設計可否從中汲取一些養分呢？這也是我開始涉獵《寫給你們看的設計書》的緣由。
      這本書偏「平面」設計——海報、廣告、傳單等。其設計目標與軟件設計有些出入，所以，親密性、對齊、重複和對比這四個原則，有些確實值得借鑑，有些只能說看看就好。