《寫給大家看的設計書》介紹了設計的四個基本原則：親密性、對齊、重複、對比。作爲一個軟件“設計師”，我也來聊聊讀過這本書之後，我對這四個原則的一點理解。
親密性
親密性原則是指：內涵相關聯的內容，在結構、關係上也應保持關聯。
以軟件設計的角度來說，一項業務所包含的功能、一個功能所包含的代碼，應該在結構、關係上保持關聯。例如把這些代碼放到同一個包下、用同一套規則來命名。這樣，當我們需要查閱、修改這個功能，需要處理哪些代碼就“一望而知”了。
很明顯，“親密性”實際上就是軟件工程中常說的“高內聚”。“高內聚”之於軟件工程，就如空氣之於人一樣：重要，卻常常被忽視。最常見的一種忽視“高內聚”原則而產生的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也是同樣的考慮。
對比
設計中進行“對比”，一般是爲了突出核心設計目的。對軟件設計來說，“對比”原則參考意義不大。
後記
最近的技術思考和積累，關注點都不在代碼或系統的細節上，而是轉向了一些業務系統或邏輯的設計上。這跟我的技術價值觀有關：技術的價值是需要體現在業務系統中的。不過這可以另外展開，這裏打住。
“設計”行業由來已久，建築設計、時裝設計、包裝設計、城市規劃設計、工業設計、平面設計……等等等等。這些設計門類都已經積累了很多經驗，軟件設計能否從中汲取一些營養呢？這也是我開始涉獵《寫給大家看的設計書》的原因。
這本書偏“平面”設計——海報、廣告、傳單等。其設計目標與軟件設計有些出入，因此，親密性、對齊、重複和對比這四個原則，有些確實值得借鑑，有些只能說看看就好。