閱讀本文大概需要 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),用虛線箭頭來表示。
結語
編程是一門技術,更加是一門藝術!
不能只滿足於寫完代碼運行結構正確就完事,時常考慮如何讓代碼更加簡練,更加容易維護,容易擴展和複用,只有這樣才能可以真正得到提高。
切身感悟:自己幾個月之前寫完的代碼,現在再來回顧,你會發現這代碼簡直了...,一團糟,甚至懷疑這代碼不是出自自己之手(絕對是自己寫的)。想着手優化,進行改進,又怕本來沒問題的功能,改出問題,影響使用,然後又進入惡性循環了。。。這種情況要切記,一定要儘可能的避免!
寫出優雅的代碼也是一種很爽的事情!!!
往期精彩回顧
歡迎關注我的公衆號「程序員的成長之路」,閱讀更多精彩!