閱讀本文大概需要 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），用虛線箭頭來表示。
結語
程式設計是一門技術，更加是一門藝術！
不能只滿足於寫完程式碼執行結構正確就完事，時常考慮如何讓程式碼更加簡練，更加容易維護，容易擴充套件和複用，只有這樣才能可以真正得到提高。
切身感悟：自己幾個月之前寫完的程式碼，現在再來回顧，你會發現這程式碼簡直了...，一團糟，甚至懷疑這程式碼不是出自自己之手（絕對是自己寫的）。想著手優化，進行改進，又怕本來沒問題的功能，改出問題，影響使用，然後又進入惡性迴圈了。。。這種情況要切記，一定要儘可能的避免！
寫出優雅的程式碼也是一種很爽的事情！！！
往期精彩回顧