前言

對于設計模式，相信很多開發者并不陌生，我在學習過程中希望把自己的一些總結和心得體會與你分享。
本專欄主要將重點放在設計模式在游戲中的應用，會結合大家熟悉的游戲場景和功能闡述設計模式在該處應用的好處。因為設計模式很多，而且許多其實在游戲中并不會有應用空間，所以部分設計模式并不會出現在本專欄中，如果是希望學習所有設計模式的同學可以去尋找其他更優質的文章。
這是我開的第幾個坑了？咕咕咕 如今已經找到工作并且現在工作也已穩定，雖然加班很多，但是我還是希望把業余時間投入到文章創作之中，會努力把之前的坑給填上的。

1. 設計模式概述

1.1 設計模式的定義

設計模式(Design Pattern)是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結，使用設計模式是為了可重用代碼、讓代碼更容易被他人理解并且保證代碼可靠性。

1.2 設計模式七大原則（概述）

1.2.1 單一職責原則(Single Responsibility Principle, SRP)

一個類只負責一個功能領域中的相應職責

1.2.2 開閉原則(Open-Closed Principle, OCP)

軟件實體應對擴展開放，而對修改關閉

1.2.3 里氏代換原則(Liskov Substitution Principle, LSP)

所有引用基類對象的地方能夠透明地使用其子類的對象

1.2.4 依賴倒轉原則(Dependence Inversion Principle, DIP)

抽象不應該依賴于細節，細節應該依賴于抽象

1.2.5 接口隔離原則(Interface Segregation Principle, ISP)

使用多個專門的接口，而不使用單一的總接口

1.2.6 合成復用原則(Composite Reuse Principle, CRP)

盡量使用對象組合，而不是繼承來達到復用的目的

1.2.7 迪米特法則(Law of Demeter, LoD)

一個軟件實體應當盡可能少地與其他實體發生相互作用

1.3 設計模式的內容

設計模式一般包含模式名稱、問題、目的、解決方案、效果等組成要素，其中關鍵要素是模式名稱、問題、解決方案和效果。

1.3.1 模式名稱(Pattern Name)

通過一兩個詞來描述模式的問題、解決方案和效果，以便更好地理解模式并方便開發人員之間的交流，絕大多數模式都是根據其功能或模式結構來命名的（GoF設計模式中沒有一個模式用人名命名，）；

1.3.2 問題(Problem)

描述了應該在何時使用模式，它包含了設計中存在的問題以及問題存在的原因；

1.3.3 解決方案(Solution)

描述了一個設計模式的組成成分，以及這些組成成分之間的相互關系，各自的職責和協作方式，通常解決方案通過UML類圖和核心代碼來進行描述；

1.3.4 效果(Consequences)

描述了模式的優缺點以及在使用模式時應權衡的問題。

1.4 設計模式的分類

1.4.1 創建型模式：

工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。

1.4.2 結構型模式：

適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

1.4.3 行為型模式：

策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。

3. 設計模式七大原則

3.1 單一職責原則(Single responsibility principle)

一個類應該只負責一項職責。

3.2 接口隔離原則(Interface Segregation Principle)

客戶端不應該依賴它不需要的接口，即一個類對另一個類的依賴應該建立在最小的接口上。

3.3 依賴倒轉原則(Dependence Inversion Principle)

依賴倒轉(倒置)的中心思想是面向接口編程，所謂“倒轉”是指抽象不應該依賴細節，而是細節應該依賴抽象。也就是高層模塊不應該依賴低層模塊，二者都應該依賴其抽象。因為相對于細節的多變性，抽象的東西要穩定的多。

3.4 里氏替換原則(Liskov Substitution Principle)

所有引用基類的地方必須能透明地使用其子類的對象。也就是在繼承關系中，子類盡量不要重寫父類的方法。繼承實際上讓兩個類耦合性增強了，特別是運行多態比較頻繁的時，整個繼承體系的復用性會比較差。
比如一種極端情況：一個類繼承了另一個類，但卻重寫了所有方法，那么繼承的意義何在？說好的復用呢？
解決方法是把原來的父類和子類都繼承一個更通俗的基類，在適當的情況下，可以通過聚合，組合，依賴等來代替。

3.5 開閉原則(Open Closed Principle)

一個軟件實體如類，模塊和函數應該對擴展開放(對提供方)，對修改關閉(對使用方)。也就是當軟件需要變化時，盡量通過擴展軟件實體的行為來實現變化，而不是通過修改已有的代碼來實現變化。用抽象構建框架，用實現擴展細節。
開閉原則是編程中最基礎、最重要的設計原則。編程中遵循其它原則，以及使用設計模式的目的就是遵循開閉原則。

3.6 迪米特法則(最少知識原則)(Demeter Principle)

即一個類對自己依賴的類知道的越少越好，核心是降低類之間的耦合。也就是說，對于被依賴的類不管多么復雜，都盡量將邏輯封裝在類的內部。對外除了提供的public 方法，不對外泄露任何信息。
避免與非直接朋友的耦合，只與直接的朋友通信，所謂的直接朋友是出現成員變量，方法參數，方法返回值中的類。而出現在局部變量中的類不是直接的朋友。也就是說，陌生的類最好不要以局部變量的形式出現在類的內部。

3.7 合成/聚合復用原則(Composite Reuse Principle)

盡量使用合成/聚合的方式，而不是使用繼承。

告知

由于這篇文章成文較早，所以很多參考文獻已不可考，再次道歉，如有相似之處，敬請諒解。