Unity3d 必備的幾種優秀的設計模式
unity程式設計眾所周知，它是屬於指令碼化，指令碼沒有一個具體的概念跟架構，
導致在專案過程中，經常出現哪裡需要實現什麼功能，就隨便新增指令碼，
結果，就造成了一片混亂，不好管理。
更有甚者，自己的寫的程式碼閒置一段時間後，再去想找某個功能的實現，都要在檢視中翻來覆去找半天。
哎!請容許我在此感嘆一聲，這還是你寫的東西麼？
因此，一個好的設計模式是多麼的重要啊，
那麼，我們在使用Unity3D開發東西的時候，指令碼架構到底應該如何來寫？
呵呵...
其實，我也給不了你們具體答案，因為每個人的開發習慣，每個團隊的開發模式也各有千秋，
so，在此我只做幾種設計模式的總結，
主要參考書籍有《設計模式》《設計模式之禪》《大話設計模式》以及網上一些零散的文章，
但主要內容還是我本人的一些經驗以及感悟。
寫出來的目的一方面是系統地整理一下，一方面也與廣大的網友分享，
至於你們到底如何使用，
望君斟酌啊!
因為設計模式對程式設計人員來說，的確非常重要。
當然，如果大家的理解跟我有所不同，歡迎留言，大家共同探討。
- 原則1：單一職責
- 原則2：里氏替換原則（子類擴充套件但不改變父類功能）
- 原則3：依賴倒置原則
- 原則4：介面隔離原則
- 原則5：迪米特法則（最少知道原則）
- 原則6：開閉原則
原則1：單一職責原則
說到單一職責原則，很多人都會不屑一顧。
因為它太簡單了，稍有經驗的程式設計師即使從來沒有讀過設計模式、從來沒有聽說過單一職責原則，在設計軟體時也會自覺的遵守這一重要原則，因為這是常識。
在軟體程式設計中，誰也不希望因為修改了一個功能導致其他的功能發生故障。
而避免出現這一問題的方法便是遵循單一職責原則。
雖然單一職責原則如此簡單，並且被認為是常識，但是即便是經驗豐富的程式設計師寫出的程式，也會有違背這一原則的程式碼存在。
為什麼會出現這種現象呢？因為有職責擴散。所謂職責擴散，就是因為某種原因，職責被分化成了更細的職責。
如：用一個類描述動物呼吸這個場景
class Animal { public void breathe(string animal) { Debug.Log(animal + "呼吸空氣"); } } public class Client { Animal animal = new Animal(); void Start() { animal.breathe("牛"); animal.breathe("羊"); animal.breathe("豬"); } } //執行結果： //牛呼吸空氣//羊呼吸空氣 //豬呼吸空氣
程式上線後，發現問題了，並不是所有的動物都呼吸空氣的，比如魚就是呼吸水的。
修改時如果遵循單一職責原則，需要將Animal類細分為陸生動物類Terrestrial，水生動物Aquatic，程式碼如下：
class Terrestrial { public void breathe(String animal) { Debug.Log(animal + "呼吸空氣"); } } class Aquatic { public void breathe(String animal) { Debug.Log(animal + "呼吸水"); } } public class Client { public static void main(String[] args) { Terrestrial terrestrial = new Terrestrial(); terrestrial.breathe("牛"); terrestrial.breathe("羊"); terrestrial.breathe("豬"); Aquatic aquatic = new Aquatic(); aquatic.breathe("魚"); } } //執行結果： //牛呼吸空氣 //羊呼吸空氣 //豬呼吸空氣 //魚呼吸水
我們會發現如果這樣修改花銷是很大的，除了將原來的類分解之外，還需要修改客戶端。
而直接修改類Animal來達成目的雖然違背了單一職責原則，但花銷卻小的多，程式碼如下：
class Animal { public void breathe(String animal) { if ("魚" == animal) { Debug.Log((animal + "呼吸水")); } else { Debug.Log((animal + "呼吸空氣")); } } } public class Client { public static void main(String[] args) { Animal animal = new Animal(); animal.breathe("牛"); animal.breathe("羊"); animal.breathe("豬"); animal.breathe("魚"); } }
可以看到，這種修改方式要簡單的多。
但是卻存在著隱患：有一天需要將魚分為呼吸淡水的魚和呼吸海水的魚，
則又需要修改Animal類的breathe方法，而對原有程式碼的修改會對呼叫“豬”“牛”“羊”等相關功能帶來風險，
也許某一天你會發現程式執行的結果變為“牛呼吸水”了。
這種修改方式直接在程式碼級別上違背了單一職責原則，雖然修改起來最簡單，但隱患卻是最大的。
還有一種修改方式：
class Animal { public void breathe(String animal) { Debug.Log(animal + "呼吸空氣"); } public void breathe2(String animal) { Debug.Log(animal + "呼吸水"); } } public class Client { public static void main(String[] args) { Animal animal = new Animal(); animal.breathe("牛"); animal.breathe("羊"); animal.breathe("豬"); animal.breathe2("魚"); } }
可以看到，這種修改方式沒有改動原來的方法，而是在類中新加了一個方法，這樣雖然也違背了單一職責原則，
但在方法級別上卻是符合單一職責原則的，因為它並沒有動原來方法的程式碼。這三種方式各有優缺點，
那麼在實際程式設計中，採用哪一中呢？
其實這真的比較難說，需要根據實際情況來確定。
我的原則是：只有邏輯足夠簡單，才可以在程式碼級別上違反單一職責原則；只有類中方法數量足夠少，才可以在方法級別上違反單一職責原則。
遵循單一職責原的優點有：
- 可以降低類的複雜度，一個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；
- 提高類的可讀性，提高系統的可維護性；
- 變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改一個功能時，可以顯著降低對其他功能的影響。
需要說明的一點是單一職責原則不只是面向物件程式設計思想所特有的，只要是模組化的程式設計，都適用單一職責原則。
原則2：里氏替換原則
肯定有不少人跟我剛看到這項原則的時候一樣，對這個原則的名字充滿疑惑。
其實原因就是這項原則最早是在1988年，由麻省理工學院的一位姓裡的女士（Barbara Liskov）提出來的。
簡單來說的話，就是當我們使用繼承時，遵循里氏替換原則。
注：類B繼承類A時，除新增新的方法完成新增功外，儘量不要重寫父類A的方法，也儘量不要過載父類A的方法。
繼承包含這樣一層含義：父類中凡是已經實現好的方法（相對於抽象方法而言），實際上是在設定一系列的規範和契約，
雖然它不強制要求所有的子類必須遵從這些契約，但是如果子類對這些非抽象方法任意修改，
就會對整個繼承體系造成破壞。而里氏替換原則就是表達了這一層含義。
繼承作為面向物件三大特性之一，在給程式設計帶來巨大便利的同時，也帶來了弊端。
比如使用繼承會給程式帶來侵入性，程式的可移植性降低，增加了物件間的耦合性，如果一個類被其他的類所繼承，
則當這個類需要修改時，必須考慮到所有的子類，並且父類修改後，
所有涉及到子類的功能都有可能會產生故障。
那就讓我們一起看看繼承的風險，如下：
class A { public int func1(int a, int b) { return a - b; } } public class Client { void Start() { A a = new A(); Debug.Log("100-50=" + a.func1(100, 50)); Debug.Log("100-80=" + a.func1(100, 80)); } }
執行結果：
100-50=50
100-80=20
後來，我們需要增加一個新的功能：完成兩數相加，然後再與100求和，由類B來負責。
即類B需要完成兩個功能：
兩數相減。
兩數相加，然後再加100。
由於類A已經實現了第一個功能，所以類B繼承類A後，只需要再完成第二個功能就可以了，程式碼如下
class B:A { public int func1(int a, int b) { return a + b; } public int func2(int a, int b) { return func1(a, b) + 100; } } public class Client { private void Start() { B b = new B(); Debug.Log("100-50=" + b.func1(100, 50)); Debug.Log("100-80=" + b.func1(100, 80)); Debug.Log("100+20+100=" + b.func2(100, 20)); } }
類B完成後，執行結果：
100-50=150
100-80=180
100+20+100=220
我們發現原本執行正常的相減功能發生了錯誤。
原因就是類B在給方法起名時無意中重寫了父類的方法，造成所有執行相減功能的程式碼全部呼叫了類B重寫後的方法，造成原本執行正常的功能出現了錯誤。
在本例中，引用基類A完成的功能，換成子類B之後，發生了異常。
在實際程式設計中，我們常常會通過重寫父類的方法來完成新的功能，這樣寫起來雖然簡單，
但是整個繼承體系的可複用性會比較差，特別是運用多型比較頻繁時，程式執行出錯的機率非常大。
如果非要重寫父類的方法，比較通用的做法是：原來的父類和子類都繼承一個更通俗的基類，原有的繼承關係去掉，採用依賴、聚合，組合等關係代替。
里氏替換原則通俗的來講就是：
子類可以擴充套件父類的功能，但不能改變父類原有的功能。它包含以下4層含義：
1.子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
2.子類中可以增加自己特有的方法。
3.當子類的方法過載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入引數更寬鬆。
4.當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。
看上去很不可思議，因為我們會發現在自己程式設計中常常會違反里氏替換原則，程式照樣跑的好好的。
所以大家都會產生這樣的疑問，假如我非要不遵循里氏替換原則會有什麼後果？
後果就是：你寫的程式碼出問題的機率將會大大增加。
原則3：依賴倒置原則
定義：高層模組不應該依賴低層模組，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。
以抽象為基礎搭建起來的架構比以細節為基礎搭建起來的架構要穩定的多。
抽象指的是介面或者抽象類，細節就是具體的實現類，使用介面或者抽象類的目的是制定好規範和契約，而不去涉及任何具體的操作，把展現細節的任務交給他們的實現類去完成。
依賴倒置原則的核心思想是面向介面程式設計，我們依舊用一個例子來說明面向介面程式設計比相對於面向實現程式設計好在什麼地方。
場景是這樣的，母親給孩子講故事，只要給她一本書，她就可以照著書給孩子講故事了。程式碼如下：
class Book { public String getContent() { return "很久很久以前有一個阿拉伯的故事……"; } } class Mother { public void narrate(Book book) { Debug.Log("媽媽開始講故事"); Debug.Log(book.getContent()); } } public class Client { void Start() { Mother mother = new Mother(); mother.narrate(new Book()); } }
執行結果：
媽媽開始講故事
很久很久以前有一個阿拉伯的故事……
執行良好，假如有一天，需求變成這樣：不是給書而是給一份報紙，讓這位母親講一下報紙上的故事，報紙的程式碼如下：
class Newspaper { public String getContent() { return "林書豪38+7領導尼克斯擊敗湖人……"; } }
這位母親卻辦不到，因為她居然不會讀報紙上的故事，這太荒唐了，只是將書換成報紙，居然必須要修改Mother才能讀。
假如以後需求換成雜誌呢？換成網頁呢？
還要不斷地修改Mother，這顯然不是好的設計。
原因就是Mother與Book之間的耦合性太高了，必須降低他們之間的耦合度才行。
我們引入一個抽象的介面IReader。
讀物，只要是帶字的都屬於讀物：
interface IReader { String getContent(); }
Mother類與介面IReader發生依賴關係，而Book和Newspaper都屬於讀物的範疇，
他們各自都去實現IReader介面，這樣就符合依賴倒置原則了，程式碼修改為：
interface IReader { String getContent(); } class Newspaper : IReader { public String getContent() { return "林書豪17+9助尼克斯擊敗老鷹……"; } } class Book : IReader { public String getContent() { return "很久很久以前有一個阿拉伯的故事……"; } } class Mother { public void narrate(IReader reader) { Debug.Log("媽媽開始講故事"); Debug.Log(reader.getContent()); } } public class Client { public static void main(String[] args) { Mother mother = new Mother(); mother.narrate(new Book()); mother.narrate(new Newspaper()); } }
執行結果：
媽媽開始講故事
很久很久以前有一個阿拉伯的故事……
媽媽開始講故事
林書豪17+9助尼克斯擊敗老鷹……
這樣修改後，無論以後怎樣擴充套件Client類，都不需要再修改Mother類了。
這只是一個簡單的例子，實際情況中，代表高層模組的Mother類將負責完成主要的業務邏輯，一旦需要對它進行修改，引入錯誤的風險極大。
所以遵循依賴倒置原則可以降低類之間的耦合性，提高系統的穩定性，降低修改程式造成的風險。
採用依賴倒置原則給多人並行開發帶來了極大的便利，
比如上例中，原本Mother類與Book類直接耦合時，Mother類必須等Book類編碼完成後才可以進行編碼，因為Mother類依賴於Book類。
修改後的程式則可以同時開工，互不影響，因為Mother與Book類一點關係也沒有。
參與協作開發的人越多、專案越龐大，採用依賴導致原則的意義就越重大。
現在很流行的TDD開發模式就是依賴倒置原則最成功的應用。
在實際程式設計中，我們一般需要做到如下3點：
1.低層模組儘量都要有抽象類或介面，或者兩者都有。
2.變數的宣告型別儘量是抽象類或介面。使用繼承時遵循里氏替換原則。
3.依賴倒置原則的核心就是要我們面向介面程式設計，理解了面向介面程式設計，也就理解了依賴倒置。
原則4：介面隔離原則
定義：客戶端不應該依賴它不需要的介面；一個類對另一個類的依賴應該建立在最小的介面上。
將臃腫的介面I拆分為獨立的幾個介面，類A和類C分別與他們需要的介面建立依賴關係。也就是採用介面隔離原則。
舉例來說明介面隔離原則：
（圖1 未遵循介面隔離原則的設計）
這個圖的意思是：類A依賴介面I中的方法1、方法2、方法3，類B是對類A依賴的實現。
類C依賴介面I中的方法1、方法4、方法5，類D是對類C依賴的實現。
對於類B和類D來說，雖然他們都存在著用不到的方法（也就是圖中紅色字型標記的方法），但由於實現了介面I，所以也必須要實現這些用不到的方法。
對類圖不熟悉的可以參照程式程式碼來理解，程式碼如下：
//介面 interface I { void method1(); void method2(); void method3(); void method4(); void method5(); } class A { public void depend1(I i) { i.method1(); } public void depend2(I i) { i.method2(); } public void depend3(I i) { i.method3(); } } class B : I { public void method1() { Debug.Log("類B實現介面I的方法1"); } public void method2() { Debug.Log("類B實現介面I的方法2"); } public void method3() { Debug.Log("類B實現介面I的方法3"); } //對於類B來說，method4和method5不是必需的，但是由於介面A中有這兩個方法， //所以在實現過程中即使這兩個方法的方法體為空，也要將這兩個沒有作用的方法進行實現。 public void method4() { } public void method5() { } } class C { public void depend1(I i) { i.method1(); } public void depend2(I i) { i.method4(); } public void depend3(I i) { i.method5(); } } class D : I { public void method1() { Debug.Log("類D實現介面I的方法1"); } //對於類D來說，method2和method3不是必需的，但是由於介面A中有這兩個方法， //所以在實現過程中即使這兩個方法的方法體為空，也要將這兩個沒有作用的方法進行實現。 public void method2() { } public void method3() { } public void method4() { Debug.Log("類D實現介面I的方法4"); } public void method5() { Debug.Log("類D實現介面I的方法5"); } } public class Client { void Start() { A a = new A(); a.depend1(new B()); a.depend2(new B()); a.depend3(new B()); C c = new C(); c.depend1(new D())); c.depend2(new D()); c.depend3(new D()); } }
可以看到，如果介面過於臃腫，只要介面中出現的方法，不管對依賴於它的類有沒有用處，實現類中都必須去實現這些方法，這顯然不是好的設計。
如果將這個設計修改為符合介面隔離原則，就必須對介面I進行拆分。
在這裡我們將原有的介面I拆分為三個介面，拆分後的設計如圖2所示：
（圖2 遵循介面隔離原則的設計）
照例貼出程式的程式碼，供不熟悉類圖的朋友參考：
interface I1 { void method1(); } interface I2 { void method2(); void method3(); } interface I3 { void method4(); void method5(); } class A { public void depend1(I1 i) { i.method1(); } public void depend2(I2 i) { i.method2(); } public void de