一、UML關係簡單描述
UML關係有六種，分別是繼承(又叫泛化)、實現、依賴、關聯、聚合、組合，其相應的耦合度由強到弱依次是：繼承 = 實現 > 組合 > 聚合 > 關聯 > 依賴。
1、繼承：繼承是一種 is-a 的關係，，在java裏用extends關鍵詞來說明這種關係，uml中用一個實線加一個空心箭頭表示這種關係。
2、實現：實現幾乎和繼承一樣，但它是一種類與接口的關係，表示類是接口所有特徵和行爲的實現，用implements關鍵詞表示，uml中使用空心三角加虛線來表示這種關係。
3、組合：組合描述的是整體與部分的關係，是一種 contains-a 的關係。其部分的生命週期與整體的生命週期一致，比如公司和部門，公司一旦倒閉，公司裏的部門就會立即解散。Uml中用實心菱形與實線表示，可以加上箭頭，也可以不加，同樣還可以加上數量關係。
4、聚合：聚合描述的也是整體與部分的關係，但他是一種 has-a 的關係。其部分的生命週期和整體的生命週期並不一致，換句話說，整體與部分的生命週期是相互獨立的，這也是聚合關係與組合關係的區別。比如小汽車和輪胎，不算備胎，一個小汽車有四個輪胎，當車子因爲其他原因報廢的時候，輪胎還是可以安在其他車子上使用的。Uml中用空心菱形和實線來表示，同樣，可以加上箭頭，也可以加上數量關係。
5、關聯：關聯關係一般用來定義對象之間靜態的、天然的結構，是一種永久的絕非偶然的關係，所以，關聯關係是一種“強關聯”的關係。在代碼中表現爲，關聯類引用了被關聯類的一個屬性，或者被關聯類作爲了關聯類的一個屬性。
舉個例子，一個成熟的男性青年與精子，兩者之間一定是一個永久的關係，絕非偶然。Uml中，用一根實線來表示關聯關係，加上箭頭就是單項關聯，不加就是雙向關聯。
6、依賴：依賴關係一般解釋爲一個類使用了另一個類，這種關係是偶然性的，是臨時性的，只有在運行時纔會表現出來，那在代碼中的體現是被依賴者
作爲了依賴者的一個方法的輸入或者輸出參數，或者僅僅是一個局部變量，也或者是一個靜態方法或屬性的調用。比如Jack切西瓜，用什麼切，用刀子切，那Jack和刀子就是一個依賴關係。Uml中用一根虛線加上箭頭來表示。
二、六大設計原則簡單介紹
1、單一職責原則：英文名稱是Single Responsibility Principle,簡稱SRP。單一職責原則的定義是：應該有且僅有一個原因引起類的變更。單一職責原則提出了一個編寫程序的標準，用職責或變化原因來衡量接口或者類設計的是否優良，但是職責和變化原因都是不可度量的，因項目而異，因環境而異。
2、里氏替換原則：英文名稱是Liskov Substitution Principle,簡稱LSP。只要父類能出現的地方子類就可以出現，而且替換爲子類也不會產生任何錯誤或異常，使用者可能根本就不需要知道是父類還是子類，但是反過來就不行，有子類出現的地方，父類未必就能適應。編碼時，在類中調用其他類時無比要使用父類或接口，如果不能使用父類或接口，則說明類的設計已經違背了LSP原則。
3、依賴倒置原則：英文名稱是Dependence Inversion Principle，簡稱DIP。DIP原則在Java語言中的體現是：
- 模塊間的依賴通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是通過接口或者抽象類產生的;
- 接口或者抽象類不依賴於實現類;
- 實現類依賴接口或者抽象類;
4、接口隔離原則：英文名稱Interface Segregation Principle。有兩種定義，第一種是“客戶端不應該依賴他不需要的接口”，即客戶端需要什麼接口就提供什麼接口，把不需要的接口剔除掉，那就需要對接口進行細化，保證接口的純潔性;第二種定義是“類間的依賴關係應該建立在最小的接口上”，它要求是最小的接口，也要求接口細化。他和單一職責是有區別的，他倆的審視角度是不一樣的，接口隔離原則要求接口的方法儘量少，而單一職責原則更注重類或者接口的職責的單一性。
5、迪米特原則：英文名稱Law of Demeter,簡稱LoD，也稱最小知識原則(Least Knowledge Principle，LKP)。含義是一個對象應該對其他對象有最少的瞭解，通俗講一個類應該對自己需耦合或者調用的類知道的最少，你的內部實現是複雜還是不復雜跟我沒關係，我只需要調用你給我的public方法。
6、開閉原則：英文名稱是Open Closed Principle。含義是一個軟件實體如類、模塊和函數應該對拓展開放，對修改關閉。開閉原則是Java世界最基礎的設計原則，上述5中原則都是開閉原則的具體形態，也就是說前五個原則就是指導設計的，而開閉原則纔是精神領袖。在實際工作中，我們應該如何應用？
- 第一、抽象約束。通過接口或者抽象類約束擴展，對擴展進行邊界限定，不允許出現在接口或者抽象類中不存在的public方法;參數類型、引用類型儘量使用接口或者抽象類，而不是實現類;抽象曾儘量保持穩定，一旦確定即不允許修改。
- 第二、封裝變化。將相同的變化封裝到一個接口或者抽象類中，將不同的變化封裝到不同的接口或者抽象類中，不應該有兩個不同的變化出現在同一個接口或者抽象類中。