本內容主要來自《深入設計模式》亞歷山大·什韋茨（Alexander Shvets）

不足之處

《大話設計模式》主要講故事，對GOF的理論不是特別深入，部分概念並沒有說清楚，比如里氏替換原則的幾點要求，三大類設計模式各個概念等等，為了補充相關知識我閱讀了《深入設計模式》，於是有了這篇前置文章。方便閱讀《大話設計模式》的入門程式員瞭解更多基礎知識。

前置知識

基礎知識

面向對象程式設計

基本理念是將數據塊及其數據相關的行為封裝成為特殊的、名為對象的實體。

UML圖相關補充

這種由各種類組成的金字塔就是層次結構。

UML 圖不會展示所有依賴——它們在真實代碼中的數量太多了。為了不讓依賴關係破壞 UML 圖，你必須對其進行精心選擇，僅展示那些對於溝通你的想法來說重要的依賴關係。

成員變數和成員方法

成員變數和方法可以統稱為類的成員。 存儲在對象成員變數中的數據通常被稱為狀態，對象中的所有方法則定義了其行為。

抽象

抽象是一種反映真實世界對象或現象中特定內容的模型，它能高精度地反映所有與特定內容相關的詳細信息，同時忽略其他內容。

介面

介面是對象的公有部分，能夠同其他對象進行交互。介面僅關心對象行為。

封裝

封裝是指一個對象對其他對象隱藏其部分狀態和行為，而僅向程式其他部分暴露有限的介面的能力。

繼承

使用繼承後，子類將擁有與其父類相同的介面。如果父類中聲明瞭某個方法，那麼你將無法在子類中隱藏該方法。你還必須實現所有的抽象方法，即使它們對於你的子類而言沒有意義。

多態

多態是指程式能夠檢測對象所屬的實際類，併在當前上下文不知道其真實類型的情況下調用其實現的能力。還可將多態看作是一個對象“假扮”為其他東西。

對象之間關係

依賴

如果修改一個類的定義可能會造成另一個類的變化，那麼這兩個類之 間就存在依賴關係。

當你在代碼中使用具體類的名稱時，通常意味著存在依賴關係。例如在指定方法簽名類型時，或是通過調用構造函數對對象進行初始化時等。

通過讓代碼依賴介面或抽象類（而不是具體類），你可以降低其依賴程度。

關聯

關聯是一個對象使用另一對象或與另一對象進行交互的關係。一個對象總是擁有訪問與其交互的對象的許可權，而簡單的依賴關係並不會在對象間建立永久性的聯繫。

一般來說，你可以使用關聯關係來表示類似於類成員變數的東西。但是它並非一定是成員變數。

聚合

聚合是一種特殊類型的關聯，用於表示多個對象之間的“一對多”、“多對多”或“整體對部分”的關係。

一個對象“擁有”一組其他對象，並扮演著容器或集合的角色。組件可以獨立於容器存在，也可以同時連接多個容器。

依賴關聯聚合組合實現繼承

設計模式簡介

演算法與模式

演算法總是明確定義達成特定目標所需的一系列步驟，而模式則是對解決方案的更高層次描述。

演算法更像是菜譜：提供達成目標的明確步驟。而模式更像是藍圖：你可以看到最終的結果和模式的功能，但需要自己確定實現步驟。

最基礎的、底層的模式通常被稱為慣用技巧。最通用的、高層的模式是架構模式。

設計模式三大類

• 創建型模式提供創建對象的機制，增加已有代碼的靈活性和 可復用性。
• 結構型模式介紹如何將對象和類組裝成較大的結構，並同時保持結構的靈活和高效。
• 行為模式負責對象間的高效溝通和職責委派。

設計模式與框架

設計模式比框架更小且更抽象。 它們實際上是對一組類的關係及 其互動方式的描述。當你從類轉向模式，並最終到達框架的 過程中，復用程度會不斷增加。模式提供的復用方式要比框架的風險小。

設計原則

封裝變化內容

找到程式中的變化內容並將其與不變的內容區分開。將變更造成的影響最小化。將程式的變化部分放入獨立的模塊中，保護其他代碼不受負面影響。

方法層面的封裝，你可以將演算法邏輯抽取到一個單獨的方法中，並對原始方法隱藏該邏輯。

類成員的封裝，你可能會在一個以前完成簡單工作的方法中添加越來越多的職責。新增行為通常還會帶來助手成員變數和方法，最終使得包含接納它們的類的主要職責變得模糊。將所有這些內容抽取到一個新類中會讓程式更加清晰和簡潔。

面向介面開發， 不是面向實現

面向介面進行開發，而不是面向實現；依賴於抽象類 型，而不是具體類。

1. 確定一個對象對另一對象的確切需求：它需執行哪些方法？
2. 在一個新的介面或抽象類中描述這些方法。
3. 讓被依賴的類實現該介面。
4. 現在讓有需求的類依賴於這個介面， 而不依賴於具體的類。 你仍可與原始類中的對象進行互動，但現在其連接將會靈活 得多。

組合優於繼承

繼承問題清單

• 子類不能減少超類的介面。
• 在重寫方法時，你需要確保新行為與其基類中的版本相容。
• 繼承打破了超類的封裝，因為子類擁有訪問父類內部詳細內容的許可權。
• 子類與超類緊密耦合。
• 通過繼承復用代碼可能導致平行繼承體系的產生。多個維度導致類層次結構膨脹！

用組合將不同“維度”的功能抽取到各自的類層次結構中。

設計原則-SOLID

從實用的角度來考量，不要把這裡的每句話當作放之四海皆準的教條。

單一職責原則

修改一個類的原因只能有一個。

如果你開始感覺在同時關註程式特定方面的內容時有些困難的話，請回憶單一職責原則並考慮現在是否應將某些類分割為幾個部分。

開放封閉原則

對於擴展，類應該是“開放”的；對於修改，類則應 是“封閉”的。

里氏替換原則

當你擴展一個類時， 記住你應該要能在不修改客戶端代碼的情況下將子類的對象作為父類對象進行傳遞。

具體要求

• 子類方法的參數類型必須與其超類的參數類型相匹配或更加抽象。
• 子類方法的返回值類型必須與超類方法的返回值類型或是其子類別相匹配。
• 子類中的方法不應拋出基礎方法預期之外的異常類型。
• 子類不應該加強其前置條件。
• 子類不能削弱其後置條件。
• 超類的不變數必須保留。
• 子類不能修改超類中私有成員變數的值。

你可以通過重新設計類層次結構來解決這個問題：一個子類必須擴展其超類的行為，因此只讀文檔變成了層次結構中的基類。可寫文件現在變成了子類，對基類進行擴展並添加了保存行為。

介面隔離原則

客戶端不應被強迫依賴於其不使用的方法。

是將介面拆分為多個部分。能夠實現原始介面的類現在只需改為實現多個精細的介面即可。其他類則可僅實現對自己有意義的介面。

創建的介面越多，代碼就越複雜。因此要保持平衡。

低層次類、高層次類

低層次的類實現基礎操作（例如磁碟操作、傳輸網路數據和 連接資料庫等）。

高層次類包含複雜業務邏輯以指導低層次類執行特定操作。

實際開發過程中，由於低層次的東西還沒有實現或不確定，你甚至無法確定高層次類能實現哪些功能。

依賴倒置原則

高層次的類不應該依賴於低層次的類。 兩者都應該依 賴於抽象介面。抽象介面不應依賴於具體實現。具體實現應該依賴於抽象介面。

如何做到依賴倒置

1. 使用業務術語來對高層次類依賴的低層次操作介面進行描述。業務邏輯應該調用名為 openReport(file) 的方法， 而不是openFile(x) 、readBytes(n) 和 closeFile(x) 等一系列方法。
2. 現在你可基於這些介面創建高層次類，而不是基於低層次的具體類。
3. 一旦低層次的類實現了這些介面，它們將依賴於業務邏輯層， 從而倒置了原始的依賴關係。

依賴倒置原則通常和開閉原則共同發揮作用：你無需修改已有類就能用不同的業務邏輯類擴展低層次的類。

參考資料

• 《Go語言核心編程》李文塔
• 《Go語言高級編程》柴樹彬、曹春輝
• 《大話設計模式》程傑
• 《深入設計模式》亞歷山大·什韋茨
• 菜鳥教程