接着上一篇我們接着往下講：
三、依賴倒置原則
定義：針對抽象編程，不要針對實現編程；高層模塊不應該依賴於底層模塊，兩個模塊都應該依賴於抽象(抽象類/接口)。高層和底層不應該直接溝通，高層底層之間，應該有一箇中間層，負責兩方溝通。
比如說一箇中國人和一個外國人（日本人，德國人，俄羅斯人...）溝通：
中國人和外國人不直接溝通，中間需要一個翻譯，中國人和外國人都依賴於翻譯。
Unity 引擎是把“依賴倒置原則”玩的很溜的一款產品。
高層依賴於底層：開發遊戲需要依賴於該平臺的底層API。
因爲編寫這些遊戲時，使用C#開發一個版本，稍作調整就能發佈到N 個平臺。
在我們發佈成不同平臺的遊戲的時候，Unity 本身就做了一個“對接”的任務，把我們的代碼裏面的API，對接到該平臺上相應的API。
高層和底層都依賴於抽象：我們的遊戲是依賴Unity 的，各個平臺的API 也是Unity 完成對接任務的。
四、里氏轉換原則
定義：①一個軟件實體如果使用的是一個父類的話，那麼一定適用於其子類。而且它察覺不出父類對象和子類對象的區別。
②在軟件裏面，把父類都替換成它的子類，軟件的行爲沒有變化；通俗點說，子類型必須能夠替換掉它們的父類型。
從生活層面中理解里氏轉換原則，一個公司的品牌就好比是一個父類，小米這個牌子就是一個父類。
小米這個品牌的產品有很多，比如：手機，電視，筆記本電腦，空氣淨化器......
這些產品就好比是繼承了父類以後，實現的子類。
[以下三句僞代碼，就是里氏轉換原則在代碼中最常見的體現]
小米品牌mi = new 小米手機(); ① ②
小米手機m5 = new 小米手機(); ②
小米手機m4 = (小米手機)mi; ③
切入點：
①子類對象可以直接賦值給父類變量；
理解：使用小米手機的用戶就是小米公司的用戶。
②子類對象可以調用父類中的成員，但是父類對象永遠只能調用自己的成員；
理解：小米手機可以打電話，還能能使用小米公司的售後服務；但是小米公司不能打電話，它只能折騰自己的用戶體驗，設計理念，品牌定位，營銷策略......
③如果父類對象中裝的是子類對象，可以將這個父類對象強轉爲子類對象；
理解：小米公司開新產品發佈會-->小米6 手機發佈會。
從unity引擎作爲切入點理解：Unity 引擎是一個父類；
Unity4.x，Unity5.x，Unity2017.x 都是這個父類下的子類。本身具備父類的功能，同時又都有自己的新功能。
五、迪米特原則（又叫最少知識／知道原則）
定義：①如果兩個類不必彼此直接通信，那麼這兩個類就不應當發生直接的相互作用。
如果其中一個類需要調用另外一個類的某一個方法的話，可以通過第三者轉發這個調用。
②一個對象應當對其他對象有儘可能少的瞭解。
例如：普通人，銀行，銀行工作人
在現實生活中，我們普通人不需要了解銀行的各種體系規章制度，當我們普通人和銀行發生業務關係的時候，我們面對的是銀行的工作人員。工作人員完成了普通人與銀行的溝通。
而在編程中，普通人，銀行，銀行工作人員，會表現成三個類。
普通人與銀行這兩個類是完全獨立的，由銀行工作人員這個類，完成二者的溝通。
當普通人或者銀行發生了代碼邏輯改變，只會影響到中間的工作人員。
但是如果普通人和銀行直接溝通，這樣耦合度就提高了，降低了普通人以及銀行這兩個類的複用性[普通人可能還需要和其他幾十個類似於銀行的機構溝通]。
1.編程中的切入點
①在類的結構設計上，每一個類都應當儘量降低成員的訪問權限。
Unity 項目開發，不要使用public 公開字段，然後面板拖拽資源賦值這種方式。應該把字段全部private 修飾，然後public 屬性公開調用。
②迪米特原則主要是強調了類與類之間的鬆耦合。
類與類之間的耦合度越低，越有利於代碼的複用，一個處於低耦合的類被修改了，不會對有關係的類造成影響。
2.Unity 迪米特原則
在Untiy4.x 時代：
我們創建一個腳本，掛載到遊戲物體身上，該腳本內就有一堆屬性可以使用。
transform，rigidoby，light，audio，collider.......
通過這些屬性，就可以直接調用當前遊戲物體身上的對應的其他組件。
但是“它知道的太多了”，不管我們這個遊戲物體身上有沒有這些組件，這些屬性都是存在的，不符合“最少知道原則”。
在Untiy5.x 時代：
這些屬性98%都廢棄掉了，只留了一個transform 屬性，用於訪問當前遊戲物體身上的Transform 組件。訪問其他的組件，必須先獲取，再訪問。
六、接口隔離原則（這裏默認了解面向對象的繼承，以及接口等相關語法格式）
定義：①客戶端不應該依賴它不需要的接口；
②一個類對另一個類的依賴應該建立在最小的接口上。
公司內有很多部門，比如：開發部，業務部，財務部等等，每個部門內都有N個員工在工作。現在我把員工要做的事情，定義成一個接口，所有員工都實現這個接口去做事情。
這個接口中定義的事情有：
工資計算，賬務管理，客戶擴展，客戶維護，產品推銷，程序開發，軟件維護。
所有的員工都實現這個接口，去做事情。現在問題就出現了，不管是哪個部門的員工，在實現了這個接口後，都有很多事情是不需要自己去做的。
當前這個接口就比較臃腫，我們需要對接口進行“功能隔離”：
財務部員工接口：
工資計算，賬務管理；
業務部員工接口：
客戶擴展，客戶維護，產品推銷；
開發部員工接口：
程序開發，軟件維護；
這樣對接口功能隔離，細分成不同部門的職責功能接口，不管是現有的員工，還是以後新加入的員工，只需要實現自己部門對應的接口即可。
1.切入點
接口要儘量小。
在定義接口的時候，接口內的方法要儘量的少，避免接口過於臃腫。
一個類由於功能上的需求，需要實現一個接口，要保證該接口內所有的方法，都是該類所需要的。
2.Unity 接口隔離原則
比如UGUI 中，就有很多接口可以用於對UI 遊戲物體進行功能擴展。
UGUI 中的UI 事件，我們在編寫UI 控制腳本時，在繼承了Mono 行爲類之後，還可以實現N 個UI 事件接口[Interface]。這裏涉及到的事件接口，它們的定義就是準守了接口隔離原則。