結合unity項目開發淺談設計模式的六大原則（二）

接着上一篇咱們接着往下講：

 

3、依賴倒置原則

定義：針對抽象編程，不要針對實現編程；高層模塊不該該依賴於底層模塊，兩個模塊都應該依賴於抽象(抽象類/接口)。高層和底層不該該直接溝通，高層底層之間，應該有一箇中間層，負責兩方溝通。

好比說一箇中國人和一個外國人（日本人，德國人，俄羅斯人...）溝通：

中國人和外國人不直接溝通，中間須要一個翻譯，中國人和外國人都依賴於翻譯。

Unity 引擎是把「依賴倒置原則」玩的很溜的一款產品。

高層依賴於底層：開發遊戲須要依賴於該平臺的底層API。

由於編寫這些遊戲時，使用C#開發一個版本，稍做調整就能發佈到N 個平臺。

在咱們發佈成不一樣平臺的遊戲的時候，Unity 自己就作了一個「對接」的任務，把咱們的代碼裏面的API，對接到該平臺上相應的API。

高層和底層都依賴於抽象：咱們的遊戲是依賴Unity 的，各個平臺的API 也是Unity 完成對接任務的。

 

4、里氏轉換原則

定義：①一個軟件實體若是使用的是一個父類的話，那麼必定適用於其子類。並且它察覺不出父類對象和子類對象的區別。

②在軟件裏面，把父類都替換成它的子類，軟件的行爲沒有變化；通俗點說，子類型必須可以替換掉它們的父類型。

從生活層面中理解里氏轉換原則，一個公司的品牌就比如是一個父類，小米這個牌子就是一個父類。

小米這個品牌的產品有不少，好比：手機，電視，筆記本電腦，空氣淨化器......

這些產品就比如是繼承了父類之後，實現的子類。

[如下三句僞代碼，就是里氏轉換原則在代碼中最多見的體現]

小米品牌mi = new 小米手機(); ① ②

小米手機m5 = new 小米手機(); ②

小米手機m4 = (小米手機)mi; ③

切入點：

①子類對象能夠直接賦值給父類變量；

理解：使用小米手機的用戶就是小米公司的用戶。

②子類對象能夠調用父類中的成員，可是父類對象永遠只能調用本身的成員；

理解：小米手機能夠打電話，還能能使用小米公司的售後服務；可是小米公司不能打電話，它只能折騰本身的用戶體驗，設計理念，品牌定位，營銷策略......

③若是父類對象中裝的是子類對象，能夠將這個父類對象強轉爲子類對象；

理解：小米公司開新產品發佈會-->小米6 手機發佈會。

 

從unity引擎做爲切入點理解：Unity 引擎是一個父類；

Unity4.x，Unity5.x，Unity2017.x 都是這個父類下的子類。自己具有父類的功能，同時又都有本身的新功能。

 

5、迪米特原則（又叫最少知識／知道原則）

定義：①若是兩個類沒必要彼此直接通訊，那麼這兩個類就不該當發生直接的相互做用。

若是其中一個類須要調用另一個類的某一個方法的話，能夠經過第三者轉發這個調用。

②一個對象應當對其餘對象有儘量少的瞭解。

 

例如：普通人，銀行，銀行工做人

在現實生活中，咱們普通人不須要了解銀行的各類體系規章制度，當咱們普通人和銀行發生業務關係的時候，咱們面對的是銀行的工做人員。工做人員完成了普通人與銀行的溝通。

而在編程中，普通人，銀行，銀行工做人員，會表現成三個類。

普通人與銀行這兩個類是徹底獨立的，由銀行工做人員這個類，完成兩者的溝通。

當普通人或者銀行發生了代碼邏輯改變，只會影響到中間的工做人員。

可是若是普通人和銀行直接溝通，這樣耦合度就提升了，下降了普通人以及銀行這兩個類的複用性[普通人可能還須要和其餘幾十個相似於銀行的機構溝通]。

 

1.編程中的切入點

①在類的結構設計上，每個類都應當儘可能下降成員的訪問權限。

Unity 項目開發，不要使用public 公開字段，而後面板拖拽資源賦值這種方式。應該把字段所有private 修飾，而後public 屬性公開調用。

②迪米特原則主要是強調了類與類之間的鬆耦合。

類與類之間的耦合度越低，越有利於代碼的複用，一個處於低耦合的類被修改了，不會對有關係的類形成影響。

2.Unity 迪米特原則

 

在Untiy4.x 時代：

咱們建立一個腳本，掛載到遊戲物體身上，該腳本內就有一堆屬性可使用。

transform，rigidoby，light，audio，collider.......

經過這些屬性，就能夠直接調用當前遊戲物體身上的對應的其餘組件。

可是「它知道的太多了」，無論咱們這個遊戲物體身上有沒有這些組件，這些屬性都是存在的，不符合「最少知道原則」。

在Untiy5.x 時代：

這些屬性98%都廢棄掉了，只留了一個transform 屬性，用於訪問當前遊戲物體身上的Transform 組件。訪問其餘的組件，必須先獲取，再訪問。

 

6、接口隔離原則（這裏默認了解面向對象的繼承，以及接口等相關語法格式）

定義：①客戶端不該該依賴它不須要的接口；

②一個類對另外一個類的依賴應該創建在最小的接口上。

 

公司內有不少部門，好比：開發部，業務部，財務部等等，每一個部門內都有N個員工在工做。如今我把員工要作的事情，定義成一個接口，全部員工都實現這個接口去作事情。

這個接口中定義的事情有：

工資計算，帳務管理，客戶擴展，客戶維護，產品推銷，程序開發，軟件維護。

全部的員工都實現這個接口，去作事情。如今問題就出現了，不論是哪一個部門的員工，在實現了這個接口後，都有不少事情是不須要本身去作的。

當前這個接口就比較臃腫，咱們須要對接口進行「功能隔離」：

財務部員工接口：

工資計算，帳務管理；

業務部員工接口：

客戶擴展，客戶維護，產品推銷；

開發部員工接口：

程序開發，軟件維護；

這樣對接口功能隔離，細分紅不一樣部門的職責功能接口，不論是現有的員工，仍是之後新加入的員工，只須要實現本身部門對應的接口便可。

 

1.切入點

接口要儘可能小。

在定義接口的時候，接口內的方法要儘可能的少，避免接口過於臃腫。

一個類因爲功能上的需求，須要實現一個接口，要保證該接口內全部的方法，都是該類所須要的。

 

2.Unity 接口隔離原則

好比UGUI 中，就有不少接口能夠用於對UI 遊戲物體進行功能擴展。

UGUI 中的UI 事件，咱們在編寫UI 控制腳本時，在繼承了Mono 行爲類以後，還能夠實現N 個UI 事件接口[Interface]。這裏涉及到的事件接口，它們的定義就是準守了接口隔離原則。