設計模式之序-UML類圖那點事兒
序
打14年年底就像寫那么一個系列，用於講設計模式的，代碼基於JAVA語言，最早接觸設計模式是大一還是大二來着，那時候網上有人給推薦書，其中就有設計模式，當時給我推薦的書我還隱約記得，叫GoF的，書名是《Design Patterns: Elements of Reusable Object-Oriented Software》，也即《設計模式》，機械出版社的將其翻譯為《設計模式-可復用面向對象軟件的基礎》。至於為什么叫做GoF，那時候因為作者是四個人，被稱為（Gang of Four），至於作者分別交什么？自行度娘或者谷歌去吧。好吧扯遠了，繼續剛才的說。雖然打算來寫這么一個基於JAVA語言實現的設計模式系列，但是由於懶病深鍾，且已病入膏肓，便無疾而終。直至前些天，群里有人並讓我教他設計模式，他是一個做前端的，因此不禁念頭又生，說道：那我寫一個系列用於講設計模式的算了，群里其他人也紛紛表示要學習。於是便有了此文。身為設計模式方面的半吊子，重溫設計模式（以前看過小菜版的大話設計模式，不過是C#寫的），文中若有不對之處，請各位大神務必指出，可不要讓我誤人子弟。閑話少說，在設計模式正文開始之前先介紹一下UML類圖。
UML以及UML類圖簡介
Unified Modeling Language (UML)又稱統一建模語言或標准建模語言。UML從考慮系統的不同角度出發，定義了用例圖、類圖、對象圖、狀態圖、活動圖、序列圖、協作圖、構件圖、部署圖等9種圖。這些圖從不同的側面對系統進行描述。系統模型將這些不同的側面綜合成一致的整體，便於系統的分析和構造。盡管UML和其它開發工具還會設計出許多派生的視圖，但上述這些圖和其它輔助性的文檔是軟件開發人員所見的最基本的構造。首先對9種圖做個簡要介紹：
1.UML用例圖與OOSE中的用例圖類似。
2.UML的類圖綜合了OMT、Booch等面向對象方法中的類圖。
3.UML狀態圖是對David Harel所提出狀態圖的改進。
4.UML活動圖的基本語義和狀態圖大致相同，它類似於許多方法（包括面向對象技術之前的一些方法）中的工作流圖。
5.UML的協作圖是通過對Booch方法的對象圖、Fusion方法的對象交互圖以及其它一些方法中的相關圖表改造而成的。
6.UML的構建圖和部署圖是在Booch方法中的模塊和進程圖（處理關系圖、處理器圖）的基礎上發展起來的。
當然在此主要介紹類圖。在UML的靜態機制中類圖是一個重點，它不但是設計人員關心的核心，更是實現人員關注的核心。建模工具也主要根據類圖來產生代碼。James Rumbaugh對類的定義是：類是具有相似結構、行為和關系的一組對象的描述符。類是面向對象系統中最重要的構造塊。類圖顯示了一組類、接口、協作以及 他們之間的關系。在UML中問題域最終要被逐步轉化，通過類來建模，通過編程語言構建這些類從而實現系統。類加上他們之間的關系就構成了類圖，類圖中還可 以包含接口、包等元素，也可以包括對象、鏈等實例。
類的UML表示
類的命名盡量應用領域中的術語，應明確、無岐義，以利於相互交流和理解。類的屬性、操作中的可見性使用＋、#、－分別表示public、protected、private。
我們通過以上的圖來分別解釋行是什么含義（感謝百度百科提供的圖）：
第一行是類的名稱，抽象類是用斜體表示。
第二行是類里面所具有的屬性：比如說如果這個類是一個動物的話，那么color、name之類的都可以在此描述。
第三行是類里面所包含的方法，比如說跑，跳，說話等等等等~
說完了類的UML表示，那么重點內容就要來了（PS：警報，前方高能、、、）
UML類圖的幾種關系
在UML類圖中，當然不可能僅僅一個類孤立的存在着，這樣也沒有什么意義，就如同人一般，必須是群體性的，既然有多個類圖，那么自然就有各種關系，就像人，人與人之間有基友，損友，諍友blablabla、、、好吧，那些都是朋友~那么類圖之間有什么關系呢？常見的有以下幾種：實現（Realization）、泛化（Generalization）、關聯（Association）、聚合（Aggregation）、組合(Composition)、依賴(Dependency)這么幾種。下面具體介紹。（PS：以下內容來自tianhai110）。
實現(Realization)
【實現關系】：是一種類與接口的關系，表示類是接口所有特征和行為的實現。
【箭頭指向】：帶三角箭頭的虛線，箭頭指向接口。
泛化(Generalization)
【泛化關系】：是一種繼承關系,它指定了子類如何特化父類的所有特征和行為例如：老虎是動物的一種。
【箭頭指向】：帶三角箭頭的實線，箭頭指向父類。
關聯（Association）
【關聯關系】：是一種擁有的關系,它使一個類知道另一個類的屬性和方法；如：老師與學生，丈夫與妻子。
關聯可以是雙向的，也可以是單向的。雙向的關聯可以有兩個箭頭或者沒有箭頭，單向的關聯有一個箭頭。
【代碼體現】：成員變量。
【箭頭及指向】：帶普通箭頭的實心線，指向被擁有者。
上圖中，老師與學生是雙向關聯，老師有多名學生，學生也可能有多名老師。但學生與某課程間的關系為單向關聯，一名學生可能要上多門課程，課程是個抽象的東西他不擁有學生。當然也會有自身的關聯。如下圖所示就是自身的關聯。
聚合（Aggregation）
【聚合關系】：是整體與部分的關系.如車和輪胎是整體和部分的關系。
聚合關系是關聯關系的一種，是強的關聯關系；關聯和聚合在語法上無法區分，必須考察具體的邏輯關系。
【代碼體現】：成員變量。
【箭頭及指向】：帶空心菱形的實心線，菱形指向整體。
組合(Composition)
【組合關系】：是整體與部分的關系.,沒有公司就不存在部門 組合關系是關聯關系的一種，是比聚合關系還要強的關系，它要求普通的聚合關系中代表整體的對象負責代表部分的對象的生命周期。
【代碼體現】：成員變量。
【箭頭及指向】：帶實心菱形的實線，菱形指向整體。
依賴(Dependency)
【依賴關系】：是一種使用的關系,所以要盡量不使用雙向的互相依賴。
【代碼表現】：局部變量、方法的參數或者對靜態方法的調用。
【箭頭及指向】：帶箭頭的虛線，指向被使用者。
各種關系的強弱順序：
泛化= 實現> 組合> 聚合> 關聯> 依賴
下面這張UML圖，比較形象地展示了各種類圖關系：
以上就是有設計模式的序章的全部內容，主要介紹了UML、UML的九種圖、類圖以及類圖間的關系。設計模式中有好些需要用到類圖間的關系，所以在序章先打下基礎了~
PS:本博客歡迎轉發，但請注明博客地址及作者~
博客地址：http://www.cnblogs.com/voidy/
博客新址：http://voidy.net
<。)#)))≦