從零開始單排學設計模式「UML類圖」定級賽

閱讀本文大概需要 3.5 分鐘。

本篇是設計模式系列的開篇，雖然之前也寫過相應的文章，但是因為種種原因後來斷掉了，而且發現之前寫的內容也很渣，不夠系統。

所以現在打算重寫，加上距離現在也有一段時間了，也算是自己的一個回顧吧！

學而時習之，不亦說乎。

從零開始單排學設計模式的國服排位之旅，今天正式開啟！

目前段位： 定級賽

這篇文章來總結下UML類圖，本來不打算講UML類圖的，因為我在學習設計模式的時候，一遇到有關UML的就會自動忽略，一看感覺就很複雜。

但是隨著學習的深入，發現不掌握UML類圖，對設計模式或者某一個框架沒有整體的把控。所以與其逃避，不如敢於面對，今天就讓我們一起來了解下什麼是UML類圖。

Let's Go！

前言

設計模式不是語法，是一種巧妙的寫法，能把程式變的更加靈活。架構模式比設計模式大，架構模式是戰略，而設計模式是戰術。

設計模式分為3大型別：建立型，行為型，結構型，總共有23種。

UML類圖

類圖描述系統中類的靜態結構，它不僅定義系統中的類，描述類之間的聯絡，如關聯、依賴、聚合等，還包括類的內部結構（類的屬性和操作）。

類圖描述的是靜態關係，在系統的整個生命週期中都是有效的。

物件圖是類圖的例項，它們的不同之處在於物件圖顯示類圖的多個物件例項，而不是實際的類。由於物件存在生命週期，所以物件圖只能在系統某一時間存在。

UML基本圖示法

虛線箭頭指向依賴；

實線箭頭指向關聯；

虛線三角指向介面；

實線三角指向父類；

空心菱形能分離而獨立存在，是聚合；

實心菱形精密關聯不可分，是組合；

上面是UML的語法，在畫類圖的時候，清理類和類之間的關係是重點。

類的關係有泛化(Generalization)、實現（Realization）、依賴(Dependency)和關聯(Association)。

其中關聯又分為一般關聯關係和聚合關係(Aggregation)，合成關係(Composition)。

基本概念

類圖（Class Diagram）：類圖是物件導向系統建模中最常見和最重要的圖，是定義其他圖的基礎。

類圖的主要是用來顯示系統中的類、介面以及它們之間的靜態結構和關係的一種靜態模型。

類圖的3個基本元件：類名、屬性、方法。

詳細解析

注：下面圖片例項中的程式碼為C#程式碼，非Java程式碼！

繼承關係

首先看到上圖這個“動物”矩形框，它就代表一個類（Class）。

類圖分三層

第一層顯示類的名稱，如果是抽象類，則就用斜體顯示。

第二層是類的特性，通常就是欄位和屬性。

第三層是類的操作，通常是方法或行為。

在看到上圖中的“飛翔”，它表示一個介面圖，與類圖的區別主要是頂端有<<interface>>顯示。

第一行是介面名稱，第二行是介面方法。

介面還有另一種表示方法，俗稱棒棒糖表示法，就是唐老鴨類實現了“講人話”的介面。

鴨子本來也有語言，只不過只有唐老鴨是能講人話的鴨子。

注意動物、鳥、鴨、唐老鴨之間的關係符號，你就會發現它們都是繼承的關係。

繼承關係用空心三角形+實現來表示。

這裡列舉的幾種鳥中，大雁是最能飛的，我讓它實現了飛翔介面。

實現介面用空心三角形+虛線來表示。

在看下圖中企鵝和氣候兩個類，企鵝是很特別的鳥，會遊不會飛。更重要的是，它與氣候有很大的關聯。我們不去討論為什麼北極沒有企鵝，為什麼它們要每年長途跋涉。

總之，企鵝需要“知道”氣候的變化，需要“瞭解”氣候規律。

當一個類“知道”另一個類時，可以用關聯（association）。

關聯關係用實現箭頭來表示。

我們再來看上圖中大眼與雁群這兩個類，大雁是群居動物，每隻大雁都屬於一個雁群，一個雁群可以又很多隻大雁。

所以它們之間就滿足聚合（Aggregation）關係。

聚合表示一種弱的“擁有”關係，體現的是A物件可以包含B物件，但B物件不是A物件的一部分。

聚合關係用實心的菱形+實線箭頭來表示。

合成（Composition，也有翻譯成“組合”的）是一種強的“擁有”關係，體現了嚴格的部分和整體的關係，部分和整體的宣告週期一樣。

在這裡鳥和其翅膀就是合成（組合）關係，因為它們是部分和整體的關係，並且翅膀和鳥的宣告週期是相同的。

合成關係用實心的菱形+實現箭頭來表示。

另外，你會注意到合成關係的連線兩端還有一個數字“1”和數字“2”，這被稱為基數。表明這一段的類可以有幾個例項，很顯然，一個鳥應該有兩隻翅膀。

如果一個類可能有無數個例項，則就用“n”來表示。關聯關係、聚合關係也可以有基數的。

動物幾大特徵，比如有新陳代謝，能繁殖。而動物要有生命力，需要氧氣、水以及食物等。也就是說，動物依賴於氧氣和水。

他們之間是依賴關係（Dependency），用虛線箭頭來表示。

結語

程式設計是一門技術，更加是一門藝術！

不能只滿足於寫完程式碼執行結構正確就完事，時常考慮如何讓程式碼更加簡練，更加容易維護，容易擴充套件和複用，只有這樣才能可以真正得到提高。

切身感悟：自己幾個月之前寫完的程式碼，現在再來回顧，你會發現這程式碼簡直了...，一團糟，甚至懷疑這程式碼不是出自自己之手（絕對是自己寫的）。想著手最佳化，進行改進，又怕本來沒問題的功能，改出問題，影響使用，然後又進入惡性迴圈了。。。這種情況要切記，一定要儘可能的避免！

寫出優雅的程式碼也是一種很爽的事情！！！

---

往期精彩回顧

房東：你敢申報，我就漲房租！京東取消年終獎！

一千行MySQL詳細學習筆記（值得學習與收藏）

你女朋友是高可用麼？

在Java中如何優雅地判空

最近整個業內狀態不太好，注意提防一些公司的小九九！

Java爬取並下載酷狗TOP500歌曲

如何計算伺服器能夠承受多大的pv？

程式設計師們，別再學習框架了！

專科程式設計師與本科程式設計師之間有什麼區別？

程式設計師的一天是怎樣過的？

從 0 開始手寫一個Tomcat，7 步搞定！

歡迎關注我的公眾號「程式設計師的成長之路」，閱讀更多精彩！