在正式講設計模式之前, 介紹一下UML類圖之間的關系還是很有必要的, 因為一些教程, 書籍, 包括我之後的文章, 都會大量使用類圖, 去描述各個類之間的關系。這是一種非常直觀, 簡約的方式。

當然, 能力, 精力有限, 這裡的UML的介紹也僅僅局限與幾種常見的類間關系。

包括: 繼承、實現、依賴、關聯、聚合、組合

 

 

在次之前, 如果看不懂類圖, 可以先看一下我之前寫的一篇文章 : 詳解八大UML類圖符號的表示法

 

 

 

 

 

一。繼承

 

指的是一個類（稱為子類、子接口）繼承另外的一個類（稱為父類、父接口）的功能，並可以增加它自己的新功能的能力，繼承是類與類或者接口與接口之間最常見的關系；

在 objective-c 中此類關系通過 : 明確標識，在設計時一般沒有爭議性；

 

UML類圖: (用空心三角形 + 實現來表示。 方向從 子類指向父類)

 

這裡附帶一下iOS類繼承圖:

 

 

 

二。實現

 

指的是一個class類實現interface接口（可以是多個）的功能；實現是類與接口之間最常見的關系；

UML類圖 (用空心三角形 + 虛線表示。 從類指向接口)

 

三。依賴

 

可以簡單的理解，就是一個類A使用到了另一個類B，而這種使用關系是具有偶然性的、、臨時性的、非常弱的，但是B類的變化會影響到A；比如某人要過河，需要借用一條船，此時人與船之間的關系就是依賴；比如人需要氧氣進行新陳代謝, 那麼人依賴氧氣, 它們之間就是依賴關系。

表現在代碼層面，為類B作為參數被類A在某個method方法中使用；

 

UML類圖 (用虛線箭頭表示, 從依賴者[人]到被依賴對象[氧氣], 注: 代碼上表現為 氧氣 作為 人 新陳代謝方法中的一個參數, 如: +新陳代謝(ino2 : 氧氣))

 

四。關聯

 

他體現的是兩個類、或者類與接口之間語義級別的一種強依賴關系，比如我和我的朋友；這種關系比依賴更強、不存在依賴關系的偶然性、關系也不是臨時性的，一般是長期性的，而且雙方的關系一般是平等的、關聯可以是單向、雙向的；

表現在代碼層面，為被關聯類B以類屬性的形式出現在關聯類A中，也可能是關聯類A引用了一個類型為被關聯類B的全局變量；

 

UML類圖 (用實現箭頭表示 )

 

 

五。聚合

 

聚合是關聯關系的一種特例，他體現的是整體與部分、擁有的關系，即has-a的關系，此時整體與部分之間是可分離的，他們可以具有各自的生命周期，部分可以屬於多個整體對象，也可以為多個整體對象共享；比如計算機與CPU、公司與員工的關系等；

表現在代碼層面，和關聯關系是一致的，只能從語義級別來區分；即 被關聯類B以類屬性的形式出現在關聯類A中，也可能是關聯類A引用了一個類型為被關聯類B的全局變量；

 

UML類圖 (用空心的菱形 + 實線箭頭表示)

 

六。組合

 

組合也是關聯關系的一種特例，他體現的是一種contains-a的關系，這種關系比聚合更強，也稱為強聚合；他同樣體現整體與部分間的關系，但此時整體與部分是不可分的，整體的生命周期結束也就意味著部分的生命周期結束；比如你和你的大腦；

表現在代碼層面，和關聯關系是一致的，只能從語義級別來區分；即 被關聯類B以類屬性的形式出現在關聯類A中，也可能是關聯類A引用了一個類型為被關聯類B的全局變量；

 

UML類圖: (用實心的菱形 + 實線箭頭表示 , 兩端可以有數字。 比如 1 個人 有 1個大腦, 那兩端就是1, 1)

 

 

對於繼承、實現這兩種關系沒多少疑問，他們體現的是一種類與類、或者類與接口間的縱向關系；

其他的四者關系則體現的是類與類、或者類與接口間的引用、橫向關系，是比較難區分的，有很多事物間的關系要想准備定位是很難的，前面也提到，這幾種關系都是語義級別的，所以從代碼層面並不能完全區分各種關系；

但總的來說，後幾種關系所表現的強弱程度依次為：組合>聚合>關聯>依賴；

下面細致的做一下比較:

 

 

 

1.聚合與組合

（1）聚合與組合都是一種結合關系，只是額外具有整體-部分的意涵。

（2）部件的生命周期不同

聚合關系中，整件不會擁有部件的生命周期，所以整件刪除時，部件不會被刪除。再者，多個整件可以共享同一個部件。
組合關系中，整件擁有部件的生命周期，所以整件刪除時，部件一定會跟著刪除。而且，多個整件不可以同時間共享同一個部件。

（3）聚合關系是“has-a”關系，組合關系是“contains-a”關系。

2.關聯和聚合

（1）表現在代碼層面，和關聯關系是一致的，只能從語義級別來區分。

（2）關聯和聚合的區別主要在語義上，關聯的兩個對象之間一般是平等的，例如你是我的朋友，聚合則一般不是平等的。

（3）關聯是一種結構化的關系，指一種對象和另一種對象有聯系。

（4）關聯和聚合是視問題域而定的，例如在關心汽車的領域裡，輪胎是一定要組合在汽車類中的，因為它離開了汽車就沒有意義了。但是在賣輪胎的店鋪業務裡，就算輪胎離開了汽車，它也是有意義的，這就可以用聚合了。

3.關聯和依賴

（1）關聯關系中，體現的是兩個類、或者類與接口之間語義級別的一種強依賴關系，比如我和我的朋友；這種關系比依賴更強、不存在依賴關系的偶然性、關系也不是臨時性的，一般是長期性的，而且雙方的關系一般是平等的。

（2）依賴關系中，可以簡單的理解，就是一個類A使用到了另一個類B，而這種使用關系是具有偶然性的、臨時性的、非常弱的，但是B類的變化會影響到A。

4.綜合比較

這幾種關系都是語義級別的，所以從代碼層面並不能完全區分各種關系；但總的來說，後幾種關系所表現的強弱程度依次為：

組合>聚合>關聯>依賴；

 

 

下面簡單舉個例子, 區分聚合和組合的關系。

大雁喜歡熱鬧害怕孤獨, 所以它們一直過著群居的生活, 這樣就有了雁群 每一只大雁都有自己的雁群。每個雁群都有好多大雁, 大雁與雁群的這種關系就可以稱之為聚合。

另外每只大雁都有兩只翅膀, 大雁與雁翅的關系就叫做組合。 有此可見, 聚合的關系明顯沒有組合緊密, 大雁不會因為它們的群主將雁群解散而無法生存, 而雁翅就無法脫離大雁而單獨生存——組合關系的類具有相同的生命周期。

 

聚合關系圖：

組合關系圖：

代碼表現:

雁群類:

 

    public  class GooseGroup
    {
        public Goose goose;


        public GooseGroup(Goose goose)
        {
            this.goose = goose;
        }
    }

 

大雁類:

 

    public class Goose
    {
        public Wings wings;

        public Goose()
        {
            wings=new Wings();
        }
    }

聚合關系的類裡含有另一個類作為參數
雁群類（GooseGroup）的構造函數中要用到大雁（Goose）作為參數把值傳進來 大雁類（Goose）可以脫離雁群類而獨立存在
組合關系的類裡含有另一個類的實例化
大雁類（Goose）在實例化之前 一定要先實例化翅膀類（Wings） 兩個類緊密耦合在一起 它們有相同的生命周期 翅膀類（Wings）不可以脫離大雁類（Goose）而獨立存在
信息的封裝性不同
在聚合關系中，客戶端可以同時了解雁群類和大雁類，因為他們都是獨立的
而在組合關系中，客戶端只認識大雁類，根本就不知道翅膀類的存在，因為翅膀類被嚴密的封裝在大雁類中。

 

 

 

大致就是這樣了。 當然, 這只是UML的一部分。 如果有興趣, 可以深入學習。

 

學習的路上, 與君共勉