從零開始單排學設計模式「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 步搞定！

關注個人公衆號閱讀更多精彩！！！