對齊 親密性 重復

《寫給大家看的設計書》介紹了設計的四個基本原則：親密性、對齊、重復、對比。作為一個軟件“設計師”，我也來聊聊讀過這本書之後，我對這四個原則的一點理解。

親密性

親密性原則是指：內涵相關聯的內容，在結構、關系上也應保持關聯。
以軟件設計的角度來說，一項業務所包含的功能、一個功能所包含的代碼，應該在結構、關系上保持關聯。例如把這些代碼放到同一個包下、用同一套規則來命名。這樣，當我們需要查閱、修改這個功能，需要處理哪些代碼就“一望而知”了。
很明顯，“親密性”實際上就是軟件工程中常說的“高內聚”。“高內聚”之於軟件工程，就如空氣之於人一樣：重要，卻常常被忽視。最常見的一種忽視“高內聚”原則而產生的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也是同樣的考慮。

對比

設計中進行“對比”，一般是為了突出核心設計目的。對軟件設計來說，“對比”原則參考意義不大。

後記

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

本文出自 “編程的摩羯男” 博客，請務必保留此出處http://winters1224.blog.51cto.com/3021203/1967240

寫給大家看的設計書——讀後筆記