背景
面向物件基礎知識，只是給了我們一個概念，如何更好的設計出良好的面向物件代碼，需要有設計原則作為支持，設計原則是核心指導思想，在這些原則的基礎上，經過不斷的實踐，抽象，提煉逐步產生了針對特定問題的設計模式，因此，學好設計模式的基礎是掌味訓本的設計原則，本文將介紹面向物件常用的設計原則，（某些原則，也可以用在系統級，模塊級等型別的設計中應用）
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種設計模式，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/228928.html
標籤：其他