【Unity】Unity C#開發設計（一）面向物件原則及類與類的關系

面向物件原則

1. 開閉原則
對擴展開放，對修改關閉，說白了就是寫好的功能少改，不要把已有的功能改壞了，如果非要改，只有兩種情況，第一種情況是原有代碼確實存在問題，第二種情況是原有代碼并沒有問題，那么就需要對原有代碼進行擴展（新增實作或子類多載），

2. 類的單一職責
一個類有且只有一個改變它的原因，

3. 面向介面編程，而非面向實作
跟設計的程序是一致的，先確定要做什么，然后再寫實作，

4. 優先使用組合而非繼承
盡量用has a，避免使用is a，
三種情況：
第一種：假如A類和B類有關聯，在A類中想做B類的事就用B類的物件或者直接呼叫靜態方法即可，
第二種：假如A類和B類有相似的地方，那么只需要實作B類的介面或抽象方法即可，
第三種：確確實實AB是父子關系，這個時候再去用繼承，并且保證子類只做父類沒有的事情，而不是去改變父類做過的事情，如果一個子類需要去修改父類的操作，基本上就是父類設計的有問題了，

5. 依賴倒置
簡單點說就是要面向介面編程，不要面向實作編程，因為介面是穩定的，實作是可變的，

6. 里氏替換原則
子類可以重寫父類的功能，但是不能改變父類的功能，

7. 介面隔離
簡單的說就是盡量不要把介面寫的太臃腫，功能能拆分盡量拆分，不要什么方法都寫到介面里，到時候實作這個介面的人會很累（因為他要實作那些他根本不需要用到的方法），

8. 迪米特法則
不要跟陌生人說話，也不要太信任陌生人，
類與類互動時，傳遞的資料量越少越好，這樣能夠降低耦合度，免得其他類對你的資料做了你不知道的事，

類與類的關系

類關系強弱對比：依賴 < 關聯 < 聚合 < 組合 < 實作 = 繼承（泛化）

1、泛化Generalization（繼承和被繼承）

泛化表示一個更泛化的元素和一個更具體的元素之間的關系，繼承關系，耦合度最高，
繼承有兩種： 1、泛化：子抽象父為泛化，
2、特化：父衍生子為特化，

2、實作Realization

類和介面的關系，表示類是介面所有特征和行為的實作，實作其實等于變相的繼承，其耦合度跟泛化基本相同，

3、關聯Association

類之間的聯系，如客戶和訂單、汽車和輪胎、公司和員工，

1. 關聯是一種結構化關系，用于表示一類物件與另一類物件之間有聯系，使一個類知道另一個類的屬性和方法，
2. 這種關系比依賴更強、不存在依賴關系的偶然性、關系也不是臨時性的，一般是長期性的，
3. 關聯可以是單向的，也可以是雙向的，雙向的關聯可以有兩個箭頭或者沒有箭頭，單向的關聯有一個箭頭，
4. 在面向物件語言中，關聯關系是通過使用成員變數來實作的，即在一個類中指定另一個類的物件為本類的成員變數，
   

關聯是類與類之間最常用的關系，從關聯的方向和數量角度上來劃分，關聯主要分為四類：
1.雙向關聯
從面向物件的角度來看，正常的關聯關系都應該是雙向的，比如學校和老師，從UML的角度來看雙向關聯又分為有箭頭和無箭頭兩個版本：
無箭頭版本：unspecified association to unspecified association(未指定關聯到未指定關聯)，連接兩個都未指明的物體關系，

有箭頭版本：navigable association to navigable association（導向性關聯到導向性關聯），參考物體與參考物體之間的關聯關系，而兩者都可以互相訪問，

2. 單項關聯：
一個類中參考另外一個類的物件作為成員變數的關系就叫單項關聯，比如客戶和地址、工人和工具，單項關聯又分為兩種情況，一種是被參考方可以訪問參考方，另一種是被訪問方不可以訪問參考方，

無X的版本：unspecified association to navigable association（未指定關聯到導向性關聯） 未指明的物體關聯參考物體（可訪問的物體）

有X的版本：Non-navigable association to navigable association（未導向性關聯到導向性關聯） 非參考物體關聯參考物體，前一個類單向知道后一個類的存在（后一個類不知道前一個類的存在），

同樣的兩個類，在不同系統上設計的方式可能有所不同，比如如果是個游戲主頁，地址對于客戶來說并不那么重要，這時候地址沒有必要反向了解用戶的資訊，但如果是個電商平臺，就有可能要根據地址來給客戶做自畫像，這個時候地址就需要擁有訪問客戶的權限，這跟雙向關聯又有所不同，雙向關聯（有箭頭版本）的雙方是必須互相了解對方的，而單項關聯只是要求被關聯者擁有訪問關聯者的權限，并不一定或者并不經常需要訪問關聯者，

3. 自關聯：
在系統中可能會存在一些類的屬性物件型別為該類本身，這種特殊的關聯關系稱為自關聯，

4. 多重性關聯Multiplicity：
多重性關聯就是我們常說的一對多、多對多，通常有以下幾種情況：

下圖表示一個班級可以有0到*個學生（星號也可以為1），

關聯關系中有兩種特別的關系，一個是聚合關系，一個是組合關系（也叫合成關系）：
1. 聚合關系（Aggregation）

• 聚合關系是關聯關系的一種，是強的關聯關系，
• 聚合關系表示的是整體和部分的關系，即has-a的關系，整體與部分可以分開，
• 整體與個體可以具有各自的生命周期，部分可以屬于多個整體物件，也可以為多個整體物件共享，
• 聚合關系也是通過成員變數來實作的，但是，關聯關系所涉及的兩個類處在同一個層次上，而聚合關系中，兩個類處于不同的層次上，一個代表整體，一個代表部分，
• 關聯與聚合僅僅從語法上是無法分辨的，必須考察所涉及的類之間的邏輯關系，
• 例如汽車由引擎、輪胎以及其它零件組成，公司與員工，大雁群與大雁，都是聚合關系，
  聚合關系的UML圖使用空心菱形作為起始端，末尾端可以是直線也可以是箭頭：
• 直線代表被聚合端不允許訪問聚合端，
  
• 箭頭代表被聚合端可以訪問聚合端，
  
  2. 組合關系（Composition）
• 組合關系是關聯關系的一種，是比聚合關系還要強的關系，
• 組合關系也是整體與部分的關系，但是整體與部分不可以分開，
• 它要求普通的聚合關系中代表整體的物件負責代表部分的物件的生命周期，
• 比如大雁和翅膀，人和頭，公司和部門都是組合關系，
  組合關系的UML圖使用實心菱形作為起始端，末尾端可以是直線也可以是箭頭：
• 直線代表部分端不允許訪問主體端，
  
• 箭頭代表部分端可以訪問主體端，
  

4、依賴Dependency

是一種使用的關系，即一個類的實作需要另一個類的協助，另一個型別作為當前型別的方法的引數或回傳值型別出現，依賴關系在面向物件語言中體現為區域變數、方法的引數或者對靜態方法的呼叫，依賴是單向的，由依賴方指向被依賴方，也就是使用方指定被使用方，
比如類ClassA依賴類ClassB：

通常情況下依賴會表現為以下幾種情況：

1. A類方法當中的一個引數使用B類；
2. A類某個方法中的區域變數使用B類；
3. A類向B類發送訊息，從而影響B類發生變化；

class ClassB
{
	public void func0()
	{
	}
	public static void statFunc()
	{
	}
}
// 情況1：A類方法當中的一個引數使用B類
class ClassA
{ 
	public void func0(ClassB classB)
	{
	}
}
// 情況2：A類某個方法中的區域變數使用B類
class ClassA
{ 
	public void func0()
	{
		ClassB b = new ClassB();
		b.func0();
	}
}
// 情況3：A類向B類發送訊息，從而影響B類發生變化
class ClassA
{ 
	public void func0()
	{
		ClassB.statFunc();
	}
}

UML中將依賴關系分為四種：使用依賴Usage、抽象依賴Abstraction、授權依賴Permission、系結依賴Binding，
一、 使用依賴Usage：
一個類使用了另一個類，以實作它的行為，具體依賴形式：
呼叫call：一個類呼叫其他類的方法，
引數parameter：一個類的方法使用其他類作為引數，
發送send：宣告信號發送者和信號接收者之間的關系，
實體化instantiate：一個類的方法中創建了另一個類的實體，

二、 抽象依賴Abstraction：
表示客戶與提供者之間的關系，客戶與提供者屬于不同的抽象事物，具體依賴形式：
跟蹤trace：宣告不同模型中的元素之間存在一些連接但不如映射精確，
精化refine：宣告具有兩個不同語意層次上的元素之間的映射，
派生derive：宣告一個實體可以從另一個實體匯出，

三、 授權依賴Permission：
表達一個事物訪問另一個事物的能力，具體依賴形式：
訪問access:允許一個包訪問另一個包的內容，
匯入import：允許一個包訪問另一個包的內容并為被訪問包的組成部分增加別名，
友元friend:允許一個元素訪問另一個元素，不管被訪問的元素是否具有可見性，

四、 系結依賴Binding：
系結依賴屬于較高級的依賴型別，用系結模板以創建新的模型元素，具體依賴形式：
系結bind:為模板引數指定值，以生成一個新的模型元素，比如泛型，

類與類的關系總結

參考一張圖總結一下各種關系：