在uml類圖中，常見的有以下幾種關係:泛化（generalization）,實現（realization），關聯（association)，聚合（aggregation），組合(***position)，依賴(dependency)。
1.泛化（generalization）
【泛化關係】是一種繼承關係，表示一般與特殊的關係，它指定了子類如何特化父類的所有特徵和行為。例如：老虎是動物的一種，即有老虎的特性也有動物的共性。
【箭頭及指向】帶三角箭頭的實線，箭頭指向父類。
泛化實現
2.實現（realization）
【實現關係】是一種類與介面的關係，表示類是介面所有特徵和行為的實現。
【箭頭及指向】帶三角箭頭的虛線，箭頭指向介面。
3.關聯（association)
【關聯關係】是一種擁有的關係，它使乙個類知道另乙個類的屬性和方法；如：老師與學生，丈夫與妻子關聯可以是雙向的，也可以是單向的。雙向的關聯可以有兩個箭頭或者沒有箭頭，單向的關聯有乙個箭頭。
【**體現】成員變數
【箭頭及指向】帶普通箭頭的實心線，指向被擁有者
上圖中，老師與學生是雙向關聯，老師有多名學生，學生也可能有多名老師。但學生與某課程間的關係為單向關聯，一名學生可能要上多門課程，課程是個抽象的東西他不擁有學生。
下圖為自身關聯：
4.聚合（aggregation）
【聚合關係】是整體與部分的關係，且部分可以離開整體而單獨存在。如車和輪胎是整體和部分的關係，輪胎離開車仍然可以存在。
聚合關係是關聯關係的一種，是強的關聯關係；關聯和聚合在語法上無法區分，必須考察具體的邏輯關係。
【**體現】成員變數
【箭頭及指向】帶空心菱形的實心線，菱形指向整體
聚合組合
5.組合(***position)
【組合關係】是整體與部分的關係，但部分不能離開整體而單獨存在。如公司和部門是整體和部分的關係，沒有公司就不存在部門。
組合關係是關聯關係的一種，是比聚合關係還要強的關係，它要求普通的聚合關係中代表整體的物件負責代表部分的物件的生命週期。
【**體現】成員變數
【箭頭及指向】帶實心菱形的實線，菱形指向整體
6.依賴(dependency)
【依賴關係】是一種使用的關係，即乙個類的實現需要另乙個類的協助，所以要盡量不使用雙向的互相依賴.
【**表現】區域性變數、方法的引數或者對靜態方法的呼叫
【箭頭及指向】帶箭頭的虛線，指向被使用者
各種關係的強弱順序：泛化=實現》組合》聚合》關聯》依賴
下面這張uml圖，比較形象地展示了各種類圖關係：
參考資料：
1. 單一職責原則（srp）
就乙個類而言，應該僅有乙個引起它變化的原因。
如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化變化可能會削弱或抑制這個類完成其它職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭到意想不到的破壞。
軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離。
2. 開放-封閉原則
是說軟體實體（類、模組、函式等）應該可以擴充套件，但是不可修改。也就說，對於擴充套件是開放的(open for extension)，對於更改是封閉的(closed for modification).
無論模組是多麼的「封閉」，都會存在一些無法對之封閉的變化。既然不可能完全封閉，設計人員必須對於他設計的模組應該對哪種變化封閉做出選擇。他必須先猜測出最具有可能發生的變化種類，然後構造抽象來隔離那些變化。
等到變化發生時立即採取行動。
在我們最初編寫**時，假設變化不會發生。當變化發生時，我們就建立抽象來隔離以後發生的同類變化。面對需求，對程式的改動是通過增加新**進行的，而不是更改現有的**。
開放-封閉原則是物件導向設計的核心所在。遵循這個原則可以帶來物件導向技術所聲稱的巨大好處，也就是可維護、可擴充套件、可復用、靈活性好。開發人員應該僅對程式中呈現出頻繁變化的那部分做出抽象，然而，對於應用程式中的每個部分都刻意地進行抽象同樣不是乙個好主意。
拒絕不成熟的抽象和抽象本身一樣重要。
3. 依賴倒轉原則
a． 高層模組不應該依賴低層模組。兩個都應該依賴抽象。
b． 抽象不應該依賴細節。細節應該依賴抽象。
4. 黎克特制代換原則
子型別必須能夠替換掉它們的父型別。
乙個軟體實體如果使用的是乙個父類的話，那麼一定適用於其子類，而且察覺不出父類物件和子類物件的區別。也就是說，在軟體裡面，把父類都替換成它的子類，程式的行為沒有變化。
5. 迪公尺特法則（最少知識原則）
如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法的話，可以通過第三者**這個呼叫。
大話設計模式觀後感 設計模式準則
一 單一職責原則 1 定義 就乙個類而言應該只有乙個引起他變化的原因 2 原因 變化的內容過多導致這個類的內容會過於臃腫，變化的因素太多容易導致其出現一些不正常的變化的時候不知是何處引發的，從而影響對系統的判斷 3 說明 編寫 的時候類 單元的功能要盡可能的分的詳細，清晰。比如要實現乙個計算器功能 ...
設計模式總結State模式
設計模式學習筆記 狀態模式 1.概述 當乙個物件的內在狀態改變時允許改變其行為，這個物件看起來像是改變了其類。2.解決的問題 主要解決的是當控制乙個物件狀態轉換的條件表示式過於複雜時的情況。把狀態的判斷邏輯轉移到表示不同的一系列類當中，可以把複雜的邏輯判斷簡單化。3.模式中的角色 3.1 上下文環境...
設計模式總結
軟體設計中散發的臭氣 1 僵化性 rigidity 很難對軟體進行改動，因為每個改動都會迫使許多對系統其他部分的改動。2 脆弱性 fragility 對系統的改動會導致系統中和改動的地方在概念上無關的許多地方出現問題。3 牢固性 immobility 很難解開系統中某部分與其他部分的糾結，從而難以使...