《小酌重構系列》已經完成了大約1/3了，在這些文章中，我使用了一些簡單的類圖來描述重構策略。在之後的文章中，我可能會借助稍微復雜一些的UML類圖來介紹。但是在此之前，我覺得有必要先介紹一下UML類圖中6大關系了。這6大關系分別是Inheritance(繼承)、Implementation(實現)、Dependency(依賴)、Association(關聯)、Aggretation(聚合)和Composition(組合)。在這6大關系中，依賴、關聯、聚合和組合是比較容易混淆的，我也會講解它們之間的區別。
UML是Unified Modeling Language的縮寫，翻譯為中文是“統一建模語言”，它是面向對象軟件的標准化建模語言。它是一個支持模型化和軟件系統開發的圖形化語言，為軟件開發的所有階段提供模型化和可視化支持，包括由需求分析到規格，到構造和配置。
不同組織不同軟件對UML的種類劃分是不同的，基本所有的UML的軟件都包含了以下4大種類
1. 用例圖UML類圖用於展現了一組對象、接口、協作和它們之間的關系。類圖描述的是一種靜態關系，在系統的整個生命周期都是有效的，是面向對象系統的建模中最常見的圖。
市面上UML的工具軟件非常多，每個人的口味不同，我就不多做介紹了，我最常用的UML工具是Visio。
當然作為一個.NET開發者，Ultimate版本的Visual Studio也提供了UML建模功能。
Inheritance表示一個類（接口）繼承另一個類（接口）的功能和屬性，用於描述父類（接口）和子類（接口）之間的關系。
繼承描述了"is a kind of "關系，例如：Manger是Employee的一種，Manager繼承了Employee的所有功能（例如：刷卡簽到、執行工作）和屬性（例如：員工姓名、入職時間）。
在UML中，繼承使用實線空心箭頭表示，空心箭頭指向父類（接口）。
Implementation表示類實現接口的功能。
在UML中，繼承使用虛線空心箭頭表示，空心箭頭指向接口。
雖然在C#中繼承和實現都使用符號:來表示（java中使用extends表示繼承，implements表示實現），但二者還是有些區別的。
1. 繼承發生在“類和類”或“接口和接口”之間，例如：子類繼承父類，子接口繼承父接口。
子類繼承父類：
public abstract class Animal
{
}
public class Bird : Animal
{
}
子接口繼承父接口：
public interface ITransportation
{
void Move();
}
public interface IVehicle : ITransportation
{
}
2. 實現發生在“類和接口”之間，例如：類實現某個接口的方法。
public interface IVehicle : ITransportation
{
}
public class Car : IVehicle
{
public void Move()
{
Console.WriteLine("汽車跑起來...");
}
}
3. 在C#中，多繼承確切地說是多實現。
不像C++語言的語法，C#的類不能同時繼承多個類。C#僅能繼承一個類，但可以同時實現多個接口。
例如：ASP.NET MVC中的Controller類，繼承了ControllerBase類，同時實現了IActionFilter, IAuthenticationFilter…等接口。
public abstract class Controller : ControllerBase, IActionFilter, IAuthenticationFilter, IAuthorizationFilter,
IDisposable, IExceptionFilter, IResultFilter, IAsyncController, IAsyncManagerContainer
{
}
在UML中，依賴關系使用虛線箭頭表示，箭頭指向被依賴的一方。
例如：在Web Service中，Client需要調用Service的操作，這就表示Client依賴於Service。
在UML中，關聯關系使用一條直線表示。
例如：Student和Teacher之間就屬於”Association”，多個Student可以關聯到一個Teacher，一個Student也可以關聯到多個Teacher。
但是Teacher和Student之間沒有“從屬”或“包含”關系。
在UML中，聚合關系使用空心菱形箭頭表示，箭頭指向整體。
例如：一個Department擁有多個Employee，Department作為整體，Department中的Employee是Department的一部分。
Department和Employee都有自己的生命周期，當一個Department被撤銷時，Employee可以轉到其他Department或離職了。
Employee轉到其他Department或離職時，Department仍然是存在的。
在UML中，組合關系使用實心菱形箭頭表示，箭頭指向整體。
例如：一套房屋有多個房間，房間是房屋的一部分。房間的生命周期依賴於房屋的生命周期，當房屋被拆掉時，房間也就不存在了。
依賴、關聯、聚合和組合都可以泛指為”依賴關系”。
當對象之間構成Association、Aggregation或Composition關系時，也建立了對象之間的依賴關系。
它們表現的依賴關系強弱程度不同，這4種關系所表現的強弱程度依次為：Composite > Aggregation > Association > Dependency。
關聯、聚合和組合是大家經常容易混淆的3種關系，這種關系最大的區別在於對象的生命周期。
1. 關聯關系：每個對象都有自己的生命周期，對象之間不存在從屬關系今天有讀者問到了一個問題：分清楚這些符號有必要嗎？
我的回答是：因團隊而異，這取決於團隊溝通和交流的方式，也取決於團隊成員的能力。
UML是一種溝通語言，你可以通過它模糊地表達一段內容，你也可以准確地描述這些內容，只要團隊的其他成員能夠領會你的意思。
溝通是以結果為向導的，你大可不必拘泥於溝通的方式，但在溝通過程中准確有效地表達尤其重要，這裡的“准確”不是指准確地使用UML符號，而是指他人能准確地領會你所表達的內容。
我個人覺得：在涉及到系統中關鍵的模型時，用確切的符號來表達關系仍然是比較重要的。
例如：在一個采購系統中，擁有采購申請 → 采購訂單這樣一個流程。采購申請由用戶選擇商品、供應商後創建；采購訂單由審核過的采購申請生成。
這裡存在3對關系：
1. 采購申請和采購申請明細的關系
2. 采購訂單和采購訂單明細關系
3. 采購申請和采購訂單之間的關系
從業務上看，1、2是一種組合關系，3是一種關聯關系。如果籠統地將1、2、3理解為依賴關系，可能會產生一些問題。
在設計過程中，如果我們正確地描述了這3對關系，那麼在刪除單據時，可根據確切的關系歸納出以下行為：
1. 刪除采購申請時，采購申請明同時被刪除（因為它們是組合關系）
2. 刪除采購訂單時，采購訂單明細同時被刪除（因為它們是組合關系）
3. 刪除采購訂單時，不影響采購申請（因為它們是關聯關系）
