面向對象基礎知識，隻是給了我們一個概念，如何更好的設計出良好的面向對象代碼，需要有設計原則作為支援。設計原則是核心指導思想，在這些原則的基礎上，經過不斷的實踐，抽象，提煉逐漸産生了針對特定問題的設計模式。是以，學好設計模式的基礎是掌握基本的設計原則。本文将介紹面向對象常用的設計原則。（某些原則，也可以用在系統級，子產品級等類型的設計中應用）
1、代碼抽象三原則
1.1 dry原則（don't repeat yourself）
意思是：不要重複自己。它的涵義是，系統的每一個功能都應該有唯一的實作。也就是說，如果多次遇到相同的問題，就需要抽象出一個通用的解決方案，不要重複開發相同的功能。
用代碼舉例：如果兩個地方需要發送短信的功能，第一個功能是發送提醒短信，第二個是發送驗證碼短信。則需要把發送短信的公用代碼進行提煉。
1.2 yagni原則（ you aren't gonna need it）
意思是：你不會需要它。出自極限程式設計的原則，指除了核心功能外，其它功能一概不要部署。背後的指導思想是盡快的讓代碼運作起來。簡單了解是盡量避免不必要的代碼，少就是多。比如：過多的日志列印，過多邏輯檢查，過多的異常處理等，如果能簡化則簡化。
1.3rule of three原則
rule of three 稱為"三次原則"，指的是當某個功能第三次出現時，才進行"抽象化"。它的含義是：當第一次用到某個功能時，寫一個特定的解決方法；第二次又用到的時候，拷貝上一次的代碼；第三次出現的時候，才着手"抽象化"，寫出通用的解決方法。
1.4 三原則之間的關系
dry強調對通用問題的抽象，yagni強調快速和簡單。rule of three相當于對前兩個原則做了一個折衷，提出了應用原則的度量。三原則的折中，有以下幾個好處。
（1）省事，避免過度設計：如果隻有一個地方用，就沒必要過度抽象，避免過度設計。
（2）容易發現模式：問題出現的場景多，容易找到通用的部分，友善進行抽象，進而找到模式。
2、grasp原則
grasp（general responsibility assignment software patterns），中文名稱：“通用職責配置設定軟體模式”，核心是自己幹自己能幹的事，自己隻幹自己的 事，也就是職責的配置設定和實作高内聚。用來解決面向對象設計的一些問題。grasp一共包括9種模式，給出了最基本的面向對象指導原則，比如：如何決定一個系統有多少對象，每個對象都包括什麼職責。
2.1 infomation expert（資訊專家）
設計類時，如果一個類有完成某個職責的所有資訊，則應該把該職責配置設定給該類。此時，該類相當于該職責的資訊專家。
例如： 常見的網上商店的購物車（shopcar），需要讓每種商品（sku）隻在購物車内出現一次，購買相同商品，隻需要更新商品的數量即可。如下圖：
針對這個問題需要權衡的是，比較商品是否相同的方法放到哪個類裡來實作呢？分析業務得知需要根據商品的編号（skuid）來唯一區分商品，而商品編号是唯一存在于商品類的，是以根據資訊專家模式，應該把比較商品是否相同的方法放在商品類裡。
2.2 creator（創造者）
用于判斷對象的初始化由哪個類發起，用于确定正确的依賴關系。實際應用中，符合下列任一條件的時候，都應該由類 a 來建立類 b，這時 a 是 b 的建立者：
a、a 是 b 的聚合
b、a 是 b 的容器
c、a 持有初始化 b 的資訊（資料）
d、a 記錄 b 的執行個體
e、a 頻繁使用 b
例如：因為訂單（order）是商品（sku）的容器，是以應該由訂單來建立商品。如下圖：
這裡因為訂單是商品的容器，也隻有訂單持有初始化商品的資訊，是以這個耦合關系是正确的且沒有辦法避免的，是以由訂單來建立商品。
2.3 low coupling（低耦合）
耦合是指兩個類之間的依賴程度。低耦合說明兩個類之間的依賴程度低。好的耦合是低耦合，有以下好處：
（1）低耦合降低了因為一個類的變化，影響其他類的範圍。
（2）使類之間的關系簡單，更容易了解。
耦合的場景
a、a 是 b 的屬性
b、a 調用 b 的執行個體的方法
c、a 的方法中引用的 b，例如 b 是 a 方法的傳回值或參數。
d、a 是 b 的子類，或者 a 實作 b
例如：creator 模式的例子裡，實際業務中需要另一個出貨人來清點訂單（order）上的商品（sku），并計算出商品的總價，但是由于訂單和商品之間的耦合已經存在了，那麼把這個職責配置設定給訂單更合适，這樣可以降低耦合，以便降低系統的複雜性。如下圖：
這裡我們在訂單類裡增加了一個 totalprice() 方法來執行計算總價的職責，沒有增加不必要的耦合。
2.4 high cohesion（高内聚）
内聚是指類内部職責的緊密程度，高内聚的類是設計良好的類，具備良好的隔離性，當内部變化了，隻要接口不改變，不影響其他部分。
例如：一個訂單資料存取類（orderdao），訂單即可以儲存為 excel 模式，也可以儲存到資料庫中；那麼，不同的職責最好由不同的類來實作，這樣才是高内聚的設計，如下圖：
這裡我們把兩種不同的資料存儲功能分别放在了兩個類裡來實作，這樣如果未來儲存到 excel 的功能發生錯誤，那麼就去檢查 orderdaoexcel 類就可以了，這樣也使系統更子產品化，友善劃分任務，比如這兩個類就可以配置設定到不同的人同時進行開發，這樣也提高了團隊協作和開發進度。
2.5 controller（控制器）
用于接收和處理系統事件的職責，一般配置給可以代表整個系統的類，一般成功xxcontroller。
有如下原則：
a、系統事件的接收與處理通常由一個進階類來代替。
b、一個子系統會有很多控制類，分别處理不同的事務。
在mvc架構中，對應的是c。
2.6 polymorphism（多态）
面向對象的三大特征一下，指一個接口可以有不同的實作，用于提高系統的靈活性和擴充性，寫出高内聚，低耦合的代碼。
例如：我們想設計一個繪畫程式，要支援可以畫不同類型的圖形，我們定義一個抽象類 shape，矩形（rectangle）、圓形（round）分别繼承這個抽象類，并重寫（override）shape 類裡的draw() 方法，這樣我們就可以使用同樣的接口（shape抽象類）繪制出不同的圖形，如下圖：
這樣的設計更符合高内聚和低耦合原則，雖然後來我們又增加了一個菱形（diamond）類，對整個系統結構也沒有任何影響，隻要增加一個繼承 shape 類就行了。
2.7 pure fabrication（純虛構）
這裡的純虛構跟我們常說說的純虛構函數意思相近。高内聚低耦合，是系統設計的終極目标，但是内聚和耦合永遠都是沖突對立的。高内聚以為這拆分出更多數量的類，但是對象之間需要協作來完成任務，這又造成了高耦合，反過來依然。該如何解決這個沖突呢？這個時候就需要純虛構模式，由一個純虛構的類來協調内聚和耦合，可以在一定程度上解決上述問題。
例如：上面多态模式的例子，如果我們的繪圖程式需要支援不同的系統，那麼因為不同系統的api結構不同，繪圖功能也需要不同的實作方式，那麼該如何設計更合适呢？如下圖：
這裡我們可以看到，因為增加了純虛構類abstractshape，不論是哪個系統都可以通過abstractshape 類來繪制圖形，我們即沒有降低原來的内聚性，也沒有增加過多的耦合，可謂魚肉和熊掌兼得。
2.8 indirection（間接）
用于隔離或組合兩個類之間的互動，避免兩個或多個事物之間直接耦合，比如使用者類和商品類，兩者的職責不同，如果之間進行直接調用，會形成強耦合（多對多關系），則可以增加一個中間者，實作對調用使用者類和商品類的聚合處理。
2.9 protected variations（防止變異）
如何設計對象、系統和子系統，使其内部的變化或者不穩定因素不會對其他元素産生不良影響？
預先識别不穩定的因素，抽象為接口，針對接口程式設計，隔離變化，如果未來發生變化，可以通過接口擴充新功能。例如：訂單支付中的支付方式是不穩定的，剛開始有網銀，快捷，之後又有了微信，支付寶。在設計時可以抽象出支付接口，當增加微信時，增加微信實作即可。
3、solid原則
3.1 單一職責原則(single responsibility principle - srp)
一個類隻有一個引起變化的原因。如果一個類有多個引起變化的原因，當其中一個變化時會影響到其他代碼。這樣代碼的内聚性不好，會導緻維護性變差，複用性降低。
用于指導對類的設計，隻有一個引起變化的原因，單一職責，設計出高内聚的類（或方法等元素）。
3.2 開放封閉原則(open closed principle - ocp)
對于軟體實體應該對擴充開放，對修改關閉。對擴充開放，是指當有新需求或需求變化時，可以僅對代碼進行擴充，就可以适應新的需求。對修改關閉是指，類或方法一旦設計完成，就不需要對其進行修改。
實作開閉原則的基礎時，找到變化，封裝變化。
用于指導可擴充的設計。
3.3 裡氏替換原則(liskov substitution principle - lsp)
一個軟體實體如果使用的是基類的話， 那麼也一定适用于其子類， 而且它根本覺察不錯使用的是基類對象還是子類對象；反過來的代換這是不成立的，
用于指導繼承體系的設計。子類出現的子類，父類可以替換，在子類設計時可以擴充父類的功能，但不能改變父類原有的功能。
3.4 最少知識原則(least knowledge principle - lkp)
最少知識原則又叫迪米特法則。一個實體應當盡量少的與其他實體之間發生互相作用，使得系統功能子產品相對獨立。也就是說一個軟體實體應當盡可能少的與其他實體發生互相作用。當一個子產品修改時，盡量少的影響其他的子產品，容易擴充，這是對軟體實體之間通信的限制，要求限制軟體實體之間通信的寬度和深度。
用于指導類之間的關系（通信）設計。
3.5 接口隔離原則(interface segregation principle - isp)
接口隔離原則的含義是：建立單一接口，不要建立龐大臃腫的接口，盡量細化接口，接口中的方法盡量少。
用于指導接口的設計，對接口進行限制。
（1）接口盡量單一，但要适度，避免過多的接口類定義。
（2）實作類隻實作需要的接口即可，當一個類實作多個接口時，調用時在具體場景隻使用單一接口即可，把不必要的隐藏起來。這樣依賴關系是最小的。有利于控制變化。
3.6 依賴倒置原則(dependence inversion principle - dip)
依賴倒置原則的核心思想是面向接口程式設計，不應該面向實作類程式設計。
（1）抽象不應該依賴于細節。細節應該依賴于抽象。
（2）高層不應該依賴于底層，兩者都應該依賴于抽象。
用于指導抽象設計，依賴穩定的，将穩定的進行抽象。
4、其他設計原則
4.1 組合/聚合複用原則（composition/aggregation reuse principle - carp）
在設計中，優先考慮使用組合，而不是繼承。繼承容易産生副作用，組合具有更好的靈活性。如：代理模式、裝飾模式、擴充卡模式等。
4.2 無環依賴原則（acyclic dependencies principle - adp）
當 a 子產品依賴于 b 子產品，b 子產品依賴于 c 子產品，c 依賴于 a 子產品，此時将出現循環依賴。在設計中應該避免這個問題，可通過引入“中介者模式”解決該問題。
4.3 共同封裝原則（common closure principle - ccp）
将易變的類放在同一個包裡，将變化隔離出來。該原則是“開放-封閉原則”的延生。
4.4 共同重用原則（common reuse principle - crp）
如果重用了包中的一個類，那麼也就相當于重用了包中的所有類，我們要盡可能減小包的大小。
4.5 好萊塢原則（hollywood principle - hp）
好萊塢明星的經紀人一般都很忙，他們不想被打擾，往往會說：don't call me, i'll call you. 翻譯為：不要聯系我，我會聯系你。對應于軟體設計而言，最著名的就是“控制反轉”（或稱為“依賴注入”），我們不需要在代碼中主動的建立對象，而是由容器幫我們來建立并管理這些對象。
4.6 保持它簡單與傻瓜（keep it simple and stupid - kiss）
不要讓系統變得複雜，界面簡潔，功能實用，操作友善，要讓它足夠的簡單，足夠的傻瓜。
4.7 慣例優于配置（convention over configuration - coc）
盡量讓慣例來減少配置，這樣才能提高開發效率，盡量做到“零配置”。很多開發架構都是這樣做的。
4.8 指令查詢分離（command query separation - cqs）
在定義接口時，要做到哪些是指令，哪些是查詢，要将它們分離，而不要揉到一起。在讀寫分離或分布式系統中應用較多。
4.9 關注點分離（separation of concerns - soc）
将一個複雜的問題分解為多個簡單的問題，然後逐個解決簡單的問題，那麼複雜的問題就解決了。
4.10 契約式設計（design by contract - dbc）
子產品或系統之間的互動，都是基于契約（接口或抽象）的，而不要依賴于具體實作。該原則建議我們要面向契約程式設計。
小結
本文介紹了常用的設計原則，基于這些原則，可以用于指導代碼設計，架構評審，code review等。在設計原則的基礎上産生了設計模式，下一篇，我們會整體介紹gof 23種設計模式。