本內容主要來自《深入設計模式》亞歷山大·什韋茨（Alexander Shvets）
不足之處
《大話設計模式》主要講故事，對GOF的理論不是特別深入，部分概念并沒有說清楚，比如里氏替換原則的幾點要求，三大類設計模式各個概念等等，為了補充相關知識我閱讀了《深入設計模式》，于是有了這篇前置文章，方便閱讀《大話設計模式》的入門程式員了解更多基礎知識，
前置知識
基礎知識
面向物件程式設計
基本理念是將資料塊及其資料相關的行為封裝成為特殊的、名為物件的物體，
UML圖相關補充
這種由各種類組成的金字塔就是層次結構，
UML 圖不會展示所有依賴——它們在真實代碼中的數量太多了，為了不讓依賴關系破壞 UML 圖，你必須對其進行精心選擇，僅展示那些對于溝通你的想法來說重要的依賴關系，
成員變數和成員方法
成員變數和方法可以統稱為類的成員， 存盤在物件成員變數中的資料通常被稱為狀態，物件中的所有方法則定義了其行為，
抽象
抽象是一種反映真實世界物件或現象中特定內容的模型，它能高精度地反映所有與特定內容相關的詳細資訊，同時忽略其他內容，
介面
介面是物件的公有部分，能夠同其他物件進行互動，介面僅關心物件行為，
封裝
封裝是指一個物件對其他物件隱藏其部分狀態和行為，而僅向程式其他部分暴露有限的介面的能力，
繼承
使用繼承后，子類將擁有與其父類相同的介面，如果父類中宣告了某個方法，那么你將無法在子類中隱藏該方法，你還必須實作所有的抽象方法，即使它們對于你的子類而言沒有意義，
多型
多型是指程式能夠檢測物件所屬的實際類，并在當前背景關系不知道其真實型別的情況下呼叫其實作的能力，還可將多型看作是一個物件“假扮”為其他東西，
物件之間關系
依賴
如果修改一個類的定義可能會造成另一個類的變化，那么這兩個類之 間就存在依賴關系，
當你在代碼中使用具體類的名稱時，通常意味著存在依賴關系，例如在指定方法簽名型別時，或是通過呼叫建構式對物件進行初始化時等，
通過讓代碼依賴介面或抽象類（而不是具體類），你可以降低其依賴程度，
關聯
關聯是一個物件使用另一物件或與另一物件進行互動的關系，一個物件總是擁有訪問與其互動的物件的權限，而簡單的依賴關系并不會在物件間建立永久性的聯系，
一般來說，你可以使用關聯關系來表示類似于類成員變數的東西，但是它并非一定是成員變數，
聚合
聚合是一種特殊型別的關聯，用于表示多個物件之間的“一對多”、“多對多”或“整體對部分”的關系，
一個物件“擁有”一組其他物件，并扮演著容器或集合的角色，組件可以獨立于容器存在，也可以同時連接多個容器，
依賴關聯聚合組合實作繼承
設計模式簡介
演算法與模式
演算法總是明確定義達成特定目標所需的一系列步驟，而模式則是對解決方案的更高層次描述，
演算法更像是菜譜：提供達成目標的明確步驟，而模式更像是藍圖：你可以看到最終的結果和模式的功能，但需要自己確定實作步驟，
最基礎的、底層的模式通常被稱為慣用技巧，最通用的、高層的模式是架構模式，
設計模式三大類
- 創建型模式提供創建物件的機制，增加已有代碼的靈活性和 可復用性，
- 結構型模式介紹如何將物件和類組裝成較大的結構，并同時保持結構的靈活和高效，
- 行為模式負責物件間的高效溝通和職責委派，
設計模式與框架
設計模式比框架更小且更抽象， 它們實際上是對一組類的關系及 其互動方式的描述，當你從類轉向模式，并最終到達框架的 程序中，復用程度會不斷增加，模式提供的復用方式要比框架的風險小，
設計原則
封裝變化內容
找到程式中的變化內容并將其與不變的內容區分開，將變更造成的影響最小化，將程式的變化部分放入獨立的模塊中，保護其他代碼不受負面影響，
方法層面的封裝，你可以將演算法邏輯抽取到一個單獨的方法中，并對原始方法隱藏該邏輯，
類成員的封裝，你可能會在一個以前完成簡單作業的方法中添加越來越多的職責，新增行為通常還會帶來助手成員變數和方法，最終使得包含接納它們的類的主要職責變得模糊，將所有這些內容抽取到一個新類中會讓程式更加清晰和簡潔，
面向介面開發， 不是面向實作
面向介面進行開發，而不是面向實作；依賴于抽象類 型，而不是具體類，
- 確定一個物件對另一物件的確切需求：它需執行哪些方法？
- 在一個新的介面或抽象類中描述這些方法，
- 讓被依賴的類實作該介面，
- 現在讓有需求的類依賴于這個介面， 而不依賴于具體的類， 你仍可與原始類中的物件進行互動，但現在其連接將會靈活 得多，
組合優于繼承
繼承問題清單
- 子類不能減少超類的介面，
- 在重寫方法時，你需要確保新行為與其基類中的版本兼容，
- 繼承打破了超類的封裝，因為子類擁有訪問父類內部詳細內容的權限，
- 子類與超類緊密耦合，
- 通過繼承復用代碼可能導致平行繼承體系的產生，多個維度導致類層次結構膨脹！
用組合將不同“維度”的功能抽取到各自的類層次結構中，
設計原則-SOLID
從實用的角度來考量，不要把這里的每句話當作放之四海皆準的教條，
單一職責原則
修改一個類的原因只能有一個，
如果你開始感覺在同時關注程式特定方面的內容時有些困難的話，請回憶單一職責原則并考慮現在是否應將某些類分割為幾個部分，
開放封閉原則
對于擴展，類應該是“開放”的；對于修改，類則應 是“封閉”的，
里氏替換原則
當你擴展一個類時， 記住你應該要能在不修改客戶端代碼的情況下將子類的物件作為父類物件進行傳遞，
具體要求
- 子類方法的引數型別必須與其超類的引數型別相匹配或更加抽象，
- 子類方法的回傳值型別必須與超類方法的回傳值型別或是其子類別相匹配，
- 子類中的方法不應拋出基礎方法預期之外的例外型別，
- 子類不應該加強其前置條件，
- 子類不能削弱其后置條件，
- 超類的不變數必須保留，
- 子類不能修改超類中私有成員變數的值，
你可以通過重新設計類層次結構來解決這個問題：一個子類必須擴展其超類的行為，因此只讀檔案變成了層次結構中的基類，可寫檔案現在變成了子類，對基類進行擴展并添加了保存行為，
介面隔離原則
客戶端不應被強迫依賴于其不使用的方法，
是將介面拆分為多個部分，能夠實作原始介面的類現在只需改為實作多個精細的介面即可，其他類則可僅實作對自己有意義的介面，
創建的介面越多，代碼就越復雜，因此要保持平衡，
低層次類、高層次類
低層次的類實作基礎操作（例如磁盤操作、傳輸網路資料和 連接資料庫等），
高層次類包含復雜業務邏輯以指導低層次類執行特定操作，
實際開發程序中，由于低層次的東西還沒有實作或不確定，你甚至無法確定高層次類能實作哪些功能，
依賴倒置原則
高層次的類不應該依賴于低層次的類， 兩者都應該依 賴于抽象介面，抽象介面不應依賴于具體實作，具體實作應該依賴于抽象介面，
如何做到依賴倒置
- 使用業務術語來對高層次類依賴的低層次操作介面進行描述，業務邏輯應該呼叫名為 openReport(file) 的方法， 而不是openFile(x) 、readBytes(n) 和 closeFile(x) 等一系列方法，
- 現在你可基于這些介面創建高層次類，而不是基于低層次的具體類，
- 一旦低層次的類實作了這些介面，它們將依賴于業務邏輯層， 從而倒置了原始的依賴關系，
依賴倒置原則通常和開閉原則共同發揮作用：你無需修改已有類就能用不同的業務邏輯類擴展低層次的類，
參考資料
- 《Go語言核心編程》李文塔
- 《Go語言高級編程》柴樹彬、曹春輝
- 《大話設計模式》程杰
- 《深入設計模式》亞歷山大·什韋茨
- 菜鳥教程
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/508846.html
標籤：設計模式
上一篇：設計模式之中介者模式