第八章 類別圖 課前指引 本章介紹類別圖的目的及其圖型符號、類別中各組成元素以及其所代表的意義。文中討論類別的屬性、類別的操作、操作的類別。類別圖中除了表達類別之外，還可以顯示出類別與類別之間的關係。本章從兩個不同的角度來討論類別之間的關係：一個是從物件的觀點，另一個是從類別的觀點。本章討論類別之間的關聯關係、聚合關係、組合關係、一般化關係、相依關係，以及繼承的關係畫法。

章節大綱 章首示意圖 8-4 一般化 8-1 目的 8-5 相依 8-2 符號 8-6 具體化 8-3 關係 備註：可依進度點選小節

章首示意圖

8-1 目的 塑模系統的靜態模型 塑模問題領域中所發掘的物件 表達系統中物件靜態的資料結構 表達系統中物件之間的關係

8-1 目的 實體關係圖 類別圖主要是用來做物件的資料結構塑模用的。 它有點類似傳統的資料庫的實體關係圖(Entity-Relation Diagram)。 但是， ERD圖並不是以物件導向的觀點來設計。 ERD是針對資料來做設計。 傳統的結構化分析與設計過程可以分為處理塑模，以及資料塑模。結構化分析與設計是以處理為中心，利用所謂的”Divide and Conquer”的方式，對於處理做細分的工作。

8-1 目的 ERD範例圖

8-1 目的 類別圖範例

8-2 符號 類別 在類別圖中，最基本的組成元素是類別。類別是用來描述一群具有相同 屬性（Attribute）與操作（Operation）的物件。在UML中，類別是以一個 長方形來表示，且此長方形被分為三個部份： 第一部分表示類別的名稱， 第二部份表示類別所具有的屬性， 第三部份則是表示類別所具有的操作。 類別的名稱要唯一，這是因為名稱是用來識別類別用的；類別的屬性用來表達 該類別在本質上所具有的特徵或是性質；類別的操作則是表示物件所具有的 行為或是能力。

8-2 符號 類別 類別封裝了屬性及操作 一個系統所牽涉的類別可能有成千上百個。 因此， 一種將類別分類的方法是依據他們在現實世界中所代表的涵義。

8-2 符號 類別 類別的分類 跟問題領域相關的類別稱為領域問題類別。 用來處理商務邏輯(business logic)的類別。 跟使用者介面相關的介面類別。 用來做資料存取的資料存取類別。 抽象化概念。

8-2 符號 類別 領域問題類別 在分析階段， 基本上我們只對領域問題類別有興趣。 領域問題類別指的是那些在討論的領域中重要的名詞概念。這種類別也稱為永續類別(persistent class)。 Persistent的意思表示這些物件所代表的資料會被儲存在資料庫裡面以做為後續的存取之用。 比如說，一個購物系統中，顧客不僅是此領域中重要的概念，並且我們希望將其資料儲存起來以供後續之用。那麼我們可以利用類別來捕捉這個重要的概念。

8-2 符號 類別 永續 在第5章討論使用案例圖時，我們介紹了如何利用stereotype來擴充UML詞彙的作法。同樣的，如果我們想要表達一個類別是必須被儲存的話，也就是說它是一個persistent class時，我們可以在類別名稱前面加上<<persistent>>這個stereotype來標記出這個類別是屬於永續類別，如圖8.x所示。在一般類別上常用的stereotype還有boundary，control，以及entity，這在後面介紹進階分析時會加以介紹。

8-2 符號 類別 永續(Persistence) 在第5章討論使用案例圖時，我們介紹了如何利用stereotype來擴充UML詞彙的作法。同樣的，如果我們想要表達一個類別是必須被儲存的話，也就是說它是一個persistent class時，我們可以在類別名稱前面加上<<persistent>>這個stereotype來標記出這個類別是屬於永續類別，如圖8.x所示。在一般類別上常用的stereotype還有boundary，control，以及entity，這在後面介紹進階分析時會加以介紹。

8-2 符號 類別 用英文的好處 這裡有一點要說明。我們在塑模類別時，會儘量使用英文。如果你所使用的CASE工具具有產生程式碼的功能時，使用英文會幫你省去後面的翻譯步驟。

8-2 符號 類別與實例 類別（Class）所代表的是一個比較抽象層次的概念。我們常常會將「類別」與「物件」這兩個詞彙互相混用，但其實這兩個詞彙所描述的概念是不一樣的，在此加以說明。所謂的實例（Instance）代表著一個類別的實現化。

8-2 符號 類別與實例 實現化也就是具體化的意思 如果這樣的說法還是太抽象的話，我們可以說所謂的instance就是利用類別所建構出來的物件，因此，instance來自於類別。以蓋房子為例，一棟房子的藍圖就好比如是類別；而依據藍圖所蓋 出來的房子就是實例。因此，類別是抽象的，實例是具體的。由類別所建構出來的實例稱為物件（Object）。

8-2 符號 屬性 一個類別所具有的性質、特徵、或是狀態稱為「屬性（Attribute）」。 例如， 跟雇員有關的一些屬性包括名字、 雇員在哪個部門工作等等；而該雇 員的膚色為何似乎就沒有那麼重要。在分析的階段中，只要是對於問題領域 是重要的屬性，就需要被包含在類別中。

8-2 符號 屬性 範例：形狀的類別 如果我們正在設計一個繪圖軟體，它可以繪製長方形(Rectangle)。那麼你會去定義一個類別就叫做長方形。對於任意一個長方形，它所擁有的性質諸如面積，周長皆可由長(length)跟寬(width)來決定。那麼長跟寬均可算是長方形類別的屬性。不同的長或是寬代表的是不同的長方形物件，也就是長方形類別的實例。

8-2 符號 屬性 範例：形狀的類別 因此，長方形的類別圖可以如下所示。

8-2 符號 屬性的能見度 對於類別的屬性我們可以宣告其「能見度（Visibility）」，這是物件導向所 提供的封裝機制（Encapsulation）。封裝的機制主要是用來保護一個類別的屬性，使得類別的屬性不會被任意修改。能見度的種類分為以下四種（圖8.6）

8-2 符號 屬性的能見度 公共的（Public）：一個具有公共的能見度的屬性代表所有的物件都可以存取與設定它的值，也就是說所有的物件都看得到它。在 UML中， 我在屬性的前面用一個加號(+)號表示該屬性具有公共的能見度。 保護的（Protected）：一個具有保護的能見度的屬性代表著只有子類別可以存取與設定它的值。在 UML中，我們在屬性的前面用一個井號(#) 號表示該屬性具有保護的能見度。

8-2 符號 屬性的能見度 類別庫（Package）：一個具有類別庫的能見度的屬性代表著只有相同類別庫之類別可以存取與設定它的值。在UML中，我們在屬性的前面用一個井號(~) 號表示該屬性具有類別庫能見度。 私有的（Private）：一個具有私有的能見度的屬性代表著該屬性只屬於它自己，任何其他的類別都不可以存取它。在UML中，我們在屬性的前面用一個減號(－)表示該屬性具有私有的能見度。

8-2 符號 屬性的能見度 屬性資料型態 每個屬性都有特定的資料型態。 屬性的資料型態有基本資料型態或是類別型態。所謂的基本資料型態，以Java語言為例，指的是：boolean、int、 long、double、float、char、String。 上圖顯示出一個長方形的長跟寬都是double的型態。請注意到，UML類別中的屬性宣告格式為 能見度 變數名稱：資料型態

8-2 符號 操作 一個類別所具有的行為或是能力稱為「操作（Operation）」，因此， 操作可以想像成是一個類別可以執行的動作或是功能。換一個角度來看，在物件導向的世界中，一個物件會執行某些動作是因為接受到外界傳遞來的訊息，一旦接受到訊息，類別就有責任對這個訊息做相對的處理，因此，操作可以看成是一個類別所應具有的責任。在分析的過程中，「能力」，「行 為」，「功能」，「訊息」，「責任」等等這些敘述均可以看成是描述操作的另一種同義詞。

8-2 符號 操作 範例：在分析階段，類別所具有的行為稱為「操作」；到了後面的設計階段，操作會被轉換成「方法（Method）」。由於方法跟實作比較有關，所以在分 析階段，大部分都是使用「操作」這個詞來描述類別的行為。與屬性一樣，我們只關心跟問題領域相關的操作。舉例來說，課程這個類別可以有「計算成績」這個操作；而購物車這個類別，則可以有「加入訂購項目」這個操作。

8-2 符號 操作 一個典型的類別包含以下三種基本型態的操作，但這並不是必須的： 1.建構子（Constructor operation）：顧名思義，此操作的目的在於建 購物件。 2.詢問的操作（Query Operation）：詢問的操作其目的是用來取得一個類別的屬性值，因此，有時候也稱為 getter。外界可以利用getter來詢問一個物件的某個屬性值。例如：購物車這個類別有訂購項目（Lineitem）以及訂購總金額（Total）這兩個屬性，要知道目前的訂購總金額，購物車應該提供一個操作：getTotal() ，好讓外界取得此資訊（圖8.9）。

8-2 符號 操作 一個典型的類別包含以下三種基本型態的操作，但這並不是必須的： 2.詢問的操作（Query Operation）：詢問的操作其目的是用來取得一個類別的屬性值，因此，有時候也稱為 getter。外界可以利用getter來詢問一個物件的某個屬性值。例如：購物車這個類別有訂購項目（Lineitem）以及訂購總金額（Total）這兩個屬性，要知道目前的訂購總金額，購物車應該提供一個操作：getTotal() ，好讓外界取得此資訊（圖8.9）。

8-2 符號 操作 一個典型的類別包含以下三種基本型態的操作，但這並不是必須的： 3.更新的操作（Update Operation）：更新的操作其目的是用來更新一個類別的屬性值。因此，有時候也稱為 setter。例如，購物車這個類別提供了一個操作 setTotal()讓外界可以利用它來設定總金額（圖8.10）。

8-2 符號 操作的注意事項 除了上述三個基本的操作之外，一個類別還可以從事與領域相關的行為或是責任，也就是說，它還包含了其他的操作。基本上，在分析階段我們只 寫出敘述性的操作，待設計階段時，這些敘述性的操作還會再次地被分解與細化。因此，在分析階段，要儘量避免去描述操作的細部邏輯（操作的發現原則會在後面章節有詳細的介紹）。在分析階段，不用太在乎，更不要把焦點放在如何去實現操作。

8-2 符號 操作的注意事項 操作也跟屬性一樣可以宣告能見度，這是物件導向所提供的封裝機制。封裝的機制用來保護一個類別的操作，使類別的操作不會被其他的物件任意呼叫。 另外，在分析階段，你不需要描繪出一個類別的所有操作。當你在檢視一個使用案例時，你可以只描繪出跟該使用案例相關的操作即可。如果你的使用案例描述是採用主詞+動詞+受詞的形式，那麼，動詞這一部份就可能是某個物件的操作。這裡所說的某個物件是指受詞。

8-2 符號 操作的注意事項 範例說明：「客戶新增訂購項目」使用案例，這句話代表的意義是顧客可以新增訂購項目至購物車中。顧客要把訂購的東西加入到購物車，所以購物車這個類別應該提供一個操作「加入訂購項目（addLineItem()）」，這是 因為購物車是接受「加入訂購項目」這個訊息的受詞（圖8.11）。

8-3 關係 類別圖除了表示領域問題中出現的類別之外，它還可以顯示類別與類別之間的關係。對於領域中的問題，會藉由許多的物件一起合作以提供解答。因此，塑模類別之間的關係是類別圖很重要的工作。

8-3 關係 物件導向世界中的關係 在物件導向的世界中，我們可以由幾個觀點來看物件之間的關係： 從類別的角度 從物件的角度來看

8-3 關係 物件導向世界中的關係 從類別角度 在類別中，有一些關係是用來表達結構上類別與類別之間的關係。例如:繼承(inheritance)的關係，介面(interface)實現化的關係。這一類的關係你可以把它看作是固定的，不會因時間的改變而有所改變的關係。用一個現實生活中的比喻，你跟你父親之間的血緣關係。我們稱之為父子關係。這個關係不會因為你成家立業搬出去住了而有所改變。

8-3 關係 物件導向世界中的關係 從物件的角度 也就是說物件們是利用什麼關係來一起合作的。 在本質上，這些物件之間的關係並沒有如上所述那種無法改變的觀念。想一想你的週遭環境事物。除了上述之家庭的關係之外，你可能有在學校修課。你跟學校之間建立了學生的關係。一但你畢了業，這個關係就消失了；還有，你可能是某個組織，社團的一員，那麼，你跟此組織或是社團就有會員的關係。這些關係與你跟你的家人的那種固定不變的關係是不一樣。在物件導向的世界中，我們稱這種關係為關聯關係(association)。

8-3 關係 物件導向世界中的關係 現時世界中物件與物件的關係相當的多而且很複雜，不會只有上述概括的幾種而已。因此，當塑模物件關係時，如果你有困難將關係歸納於哪一種類的話，不要覺得奇怪。

8-3 關係 關聯 物件導向的世界中，物件與物件彼此之間以互相傳遞訊息來完成一項工作，猶如我們在現實生活中的情境，而關聯關係所代表的意思就是在建立類別之間彼此互通訊息的管道。有了這個管道，物件與物件之間才可以互相傳遞訊息，完成所需完成的工作。關聯關係代表著類別之間結構上的連結，表達的方式是在參與該關係的兩方使用一條實線來連結，如圖8.12 所示。

8-3 關係 關聯 講到關聯關係就必須提到在設計上的影響。圖 8.13顯示四個類別以及它們之間的連結。從圖上我們可以很清楚的看出左圖中四個類別之間的關聯比較鬆散，右圖中四個類別之間的關聯比較緊密。

8-3 關係 關聯 我們可以試想一下，如果類別C被刪除時會造成什麼樣的影響呢？從圖8.14我們可以看到左圖中只有類別B與類別C之間的關聯消失了，而右圖顯示 類別A與類別C，類別B與類別C，類別D與類別C之間的關聯都消失了。因此，在結構上，右圖所帶來的破壞力比左圖來的大，因為它同時影響了其他 三個類別。套一句設計上的術語：這是因為右圖中的類別具有高耦合度。

8-3 關係 關聯

8-3 關係 關聯 耦合度 關聯關係依其結合的程度（Degree of Coupling）而分為不同形式的關聯關係。所謂的結合度是用來量度兩個物件(類別)之間的依賴程度，又稱為耦合度。當參與關係的兩個物件彼此必須依靠對方，無法單獨存在，我們 說它們是高耦合度。如果一個物件可以獨立存在，但是如果沒有另一個物件的幫忙會無法完成「某些」事項，我們可以說這些物件具有低耦合度。如果兩個物件互不溝通，也沒有必要分享資料，我們說這些物件是零耦合度。

8-3 關係 關聯 凝聚力 與耦合度相關的觀念稱為凝聚力，這在「第13章：操作」會有詳細的介紹。上面的例子是用來說明關聯關係設計的良莠會對耦合度與凝聚力造成相當的影響，進而影響到系統的設計以及將來的維護以及功能擴充。因此，從事物件導向分析時，必須謹記的一個原則：在所建立的物件中，它們之間的關係應該僅可能地鬆散，但又必須能有效地完成它們所該執行的工作。也就是說該有的關聯關係才需要有，千萬不要繪製多餘的關聯關係造成高耦合的現象。

8-3 關係 關聯 關係的名稱 對於任意兩個相關聯的類別，我們可以在關聯關係的連結線上加上關係名稱（Name）。舉例來說，人跟車子可以有這樣的關係：人擁有車、人開車、人租車等關係（圖8.15）。這個例子是在說明參與一個關係的雙方類別 有可能是相同的，但是之間想要表達的關係卻不同。當我們所要表達的關係其語意很清楚時，可以省略掉關係名稱，不然，對於任何的關聯關係最好提供一些語意上可以恰當地表達該關係的解釋，才不至於造成閱讀者的混淆以及疑惑。

8-3 關係 關聯 關係的名稱

8-3 關係 關聯 範例：關係的名稱 舉例來說，學生修課表示了「學生」與「課程」之間的關係。對於課 程，我們還有「老師教導課程」的關係。因此，在結構上，我們可以將此三 個類別及其關聯繪製如圖8.16所示。 圖8.16表示給定一個學生，我們可以找出他所修的課程；給定一個課程，我們可以找出修此課程的學生。同樣的解釋情況也適用於老師與課程的關係。

8-3 關係 關聯 關係的互通性 在關聯關係的互通性（Navigability）中，沒有箭頭的直線代表著彼此雙方都知道對方的存在，彼此雙方都可以互通訊息。有時候，我們希望表達訊息的傳遞是單向的，那麼我們可以用只帶有單方向箭頭的直線來繪製此 概念。例如，一個訂單可以有許多訂購項目；給定一個訂單，我們可以找出訂購項目，但訂購項目不需要知道它是屬於哪個訂單，此種情況可以塑模如圖8.17所示。

8-3 關係 關聯 角色名稱 在關聯關係中，我們可以給定參與物件在關係中所扮演的角色（Role）。舉例來說，對於一個航空班機資訊系統，我們可能有的兩個類別 為航班和飛機，飛機被指定某個航班，而一個航班也有指定的飛機。此種情況可以塑模如圖8.18所示。

8-3 關係 關聯 多重性 在關係連線的兩端，我們可以給出多重性。多重性用來表示參與此關係之物件的數量。其表法有下列幾種： 名稱 表法 例子 恰好一個 1 一個系有一個系主任 零個或是更多 0⋯* 教師有零個或是多個行政工作 一個或是更多 1⋯* 學生主修一個或是多個學位 零或是一個 0⋯1 教師有一個或是零個計畫補助 指定範圍 2⋯4 職員一年可以享有兩個到四個假期

8-3 關係 關聯 多重性 範例說明：從圖8.19我們可以看出，一個學生可以修1到5門課程；一門 課程可能沒有人修（0）或是有很多人修（*）；老師可以教導一門以上的課 程；或是一門課程只有1位老師。

8-3 關係 關聯 反身關聯(reflexive association) 反身關聯指的是相同類別中的物件間彼此關係。 上圖在表達一位主管管理多位操作員。主管以及操作員都是由員工類別來表示。

8-3 關係 關聯 反身關聯(reflexive association) 程式碼 在此，讓我們先將焦點轉移一下。先來看看關聯關係在程式碼中是如何體現的。相信對於有物件導向程式設計基礎的讀者會有一個比較具體的了解。我們知道關聯關係代表物件與物件在結構上的連結。那麼，在程式碼中，這種關係看起到底是像什麼？

8-3 關係 關聯 反身關聯(reflexive association) 程式碼看關聯關係 我們利用Java語言來解說關聯的概念。比方說，上面所提到的航班跟飛機之間的關聯關係。一架飛機會有它所屬的指定航班，而一個航班也會指派某一架飛機來飛航。 它的對應程式碼則為: public class Flight {private AirPlane assignedPlane;} public class AirPlane {private Flight assignedFlight;}

8-3 關係 關聯 你可以看到，關聯關係表示一個類別被當作是另一個類別的類別變數。你也可以說一個類別被當作是另一個類別的屬性或是資料成員。因此，當類別A使用類別B來當作其類別變數時，它所隱含的意思就是類別A與類別B是相關聯的。因此，這是一種類別之間結構上的關係。

8-3 關係 聚合 聚合（Aggregation）是一種特殊的關聯關係，它是用以表達「整體和部份」的關係，它也隱含著所謂包含（Include）的關係。因此，聚合的關係 可以用英文的“is-part-of”，“has-a”或是　“has-parts”語意上的關係來表示。也就是說，聚合的關係不只是指出物件相互了解的關係， 更是它們 被組合起來以形成一個新的更複雜的物件。在UML中，聚合關係以一個空的菱形來表示代表整體的一方。如圖8.22所示，一個球隊有球員，球隊如果沒了，球員還可以到別的球隊打球（聚合）。

8-3 關係 組合 組合（Composition）關係是一種比聚合關係更強的包含關係。在一個聚合的關係中，如果整體的消失會造成部分（Parts）的消失，那麼這個聚合 是一種組合關係。如圖8.22所示，一本書包含有很多章節，如果書沒了，章節也就沒了（組合）。

8-3 關係 組合還是聚合 任何一個購物系統中都會有訂單以及訂購項目。從上面的定義中，你認為訂單與訂購項目之間的關連會是組合還是聚合？答案是組合。當訂單被刪除了，與其相關的各項訂購資料也會一併被刪除掉，這是因為它已經沒有存在的意義了。 程式碼 同樣地，我們利用Java語言來看一下在程式碼中這種關係是如何體現的。 public class Team {private Player[] players;} public class Player{// 屬性}

8-3 關係 關係的強弱

8-4 一般化 一般化（Generalization）的關係是一種分類的關係（Taxonomic Relationship），而此關係將比較一般的元素（稱為父類別）跟比較特別的元素（稱為子類別）分類。子類別除了跟父類別完全一致之外，它還另外具有其他的父元素所沒有的成分。除了類別圖可以有一般化的關係之外，一般 化的關係也可以應用在使用案例等相關的UML圖中。

8-4 一般化 繼承的觀念 在類別圖中，一般化的關係是將一組有共通性質的物件予以組織化的程序。一般化講的其實就是物件導向程式語言中的繼承關念，它可以用英文中 的“is-a”或是“is a-kind-of”關係來表示。一個判斷一般化的簡單原則就是：在中文裡頭你如果可以用「物件A是物件B的一種」這句話來表達時，A跟B之間就可能存在著一般化的關係。例如：秘書跟工程師都是雇員的一種，而雇員跟客戶都是人的一種。

8-4 一般化 一般化的關係 在類別圖中，透過一般化的關係，父類別的所有特徵、性質以及操作都 會自動被子類別所繼承。也就是說子類別不需要再去定義它們，就可以自動 擁有。這也是一般化關係所帶來的好處。適當地使用一般化的關係，也可以 降低模型的複雜度，讓模型變得更好擴展以及延伸。

8-4 一般化 一般化的關係 在UML中，一般化關係的表法是一條有著空心三角型的直線，畫法是從 子類別連接到父類別，如圖8.24所示。

8-4 一般化 程式語言中 在Java語言中，一般化關係是利用 extends 來表示。 public class Parent{//} public class Child extends Parent{//}

8-4 一般化 範例：水果的一般化

8-4 一般化 範例 對於一個校務資訊系統，它的使用者可能是學校授課的教授（Professor）或者是各個不同層級的職員（Staff），而不管是哪種使用者，相同的就是他們都會有姓名、住址等屬性；而不同的地方在於，不同的角色所服務的場所會不同。比如說，老師屬於其服務的科系，而職員們則是分屬於不同的行政部門（圖8.26）。對於相同的屬性，我們可以將它們歸為一類，利用父類別來塑模；而不同的屬性，則是分別屬於各子類別。

8-4 一般化 範例

8-5 相依 從UML的定義來看，相依（Dependency）關係是指兩個類別之間語意上的依賴關係。講的白話一點，就是說當一個類別「使用（Use）」到其他類別所提供的服務時，我們稱這兩個類別有相依關係。

8-5 相依 使用的意義 那麼，所謂的使用（Use）到底又是在說什麼呢？當一個類別A會傳送訊息（Passing Message）給另一個類別B時，我們說類別A使用到類別B所提供的服務。因此，類別A依賴於類別B；而所謂的類別A傳送訊息給類別B，也就是說類別 A呼叫了類別B的操作（方法）。

8-5 相依 相依關係的符號 相依關係的符號表法是用一條帶有箭頭的虛線來表示，其箭頭是由使用類別指向被使用類別，如圖8.27顯示出類別A（ClassA）相依於類別B（ClassB）。

8-5 相依 相依關係的符號 在相依關係中，我們可以加上一些stereotype來說明此相依關係的真正意思。UML本身定義了以下幾個與相依性有關的關鍵字：access、bind、derive、import、refine、trace、use，所以，我們可以利用它們將圖8.27繪製成如圖8.28所示。

8-5 相依 相依關係的符號 除了類別圖會用到相依關係，類別庫、使用案例等也都可以使用它來塑模。圖8.29顯示了控制類別庫（Controller Package）相依於領域類別庫（Domain Package）的關係。

8-5 相依 相依關係的符號 讓我們將焦點轉移，看看相依關係在程式碼中是如何體現的，這樣對於有物件導向程式設計基礎的讀者會有一個比較具體的了解。讓我們假設有兩個類別Class1與Class2具有相依的關係，並且給出這兩個類別的一些操作，如圖8.30。

8-5 相依 程式碼 根據相依關係的含義，相依關係可能存在於以下幾種情況： 1.一個其他類別的區域變數（Local Variable） 這種情形可以用下列程式碼來表達以說明Class1相依於Class2： public class Class1{public void method1() {Class2 p = new Class2(); // 其他敘述 p.doSomthing();}}

8-5 相依 程式碼 根據相依關係的含義，相依關係可能存在於以下幾種情況： 2.參照（Has a Reference）到其他的物件 這是類似於上圖的情形。 3.在操作的參數中使用到其他類別 public class Class1 {public void method1(Class2 p) {//p.doSomthing();}}

8-5 相依 程式碼 根據相依關係的含義，相依關係可能存在於以下幾種情況： 4.使用到一個類別的static method public class Class1 {public void method1() {//Class2.staticMethod();} }

8-5 相依 相依關係與關聯關係 看完了關聯與相依關係，不知道讀者會不會對於這兩個關係所闡述的概念有點混淆。從相依關係的定義來看，它說的是一個類別呼叫了另一個類別 的操作；而從關聯關係的結構上來看，如果類別A與類別B互相有關聯，那麼類別A當然有辦法可以呼叫類別B的操作，不是嗎？那麼我們可不可以說關聯關係是相依關係的一種呢？答案是可以的。這裡要說明的重點是：關聯關係表達出類別之間的強耦合度；相依關係表達出類別之間的弱耦合度。

8-5 相依 相依關係與關聯關係 你跟Pizza店 我們可以把相依關係看成是一種相當弱的關聯關係，它並沒有關聯關係中那種「擁有」的涵義。舉個例子說明，你應該曾經打過電話要外帶Pizza，所以「你」跟「Pizza店」有著相依的關係，因為你使用了Pizza店所提供的 服務。可是，你不需要去「擁有」Pizza店，Pizza店並不是你的一部份。如果這家Pizza店的東西不好吃，下次可以換成漢堡店，你可以從此不再向這家 Pizza店買Pizza。所以，「你」跟「Pizza店」不會是關聯關係；也就是說，「你」跟「Pizza店」並沒有結構上的關聯。此關係塑模如圖 8.31。

8-5 相依 相依關係與關聯關係 你跟Pizza店 也許有人會問：「可是Pizza店真的「有」很多的顧客啊!」，所以顧客跟Pizza店是有關聯的，為什麼不可以用關聯關係塑模成如圖8.32所示？

8-5 相依 相依關係與關聯關係 它的理由在於Pizza店是會「有」很多顧客來消費，但是這些顧客不會無時不刻跟著Pizza店，顧客不可能是Pizza店的屬性（還記得關聯關係其實是 在表達類別型態的屬性嗎？）。這就好比如說學生用筆寫作業，這支筆不好寫，就換另一支筆來寫，筆不會跟著學生，筆不是學生這個概念的一部分，學生只是使用筆所提供的服務來完成作業。所以學生與筆的關係是「使用」而不是「有」，雖然我們在口語上是說成學生有筆（圖8.33）。因此，在塑模相依以及關聯關係時，對於要表達的語意必須要小心去探究其真實的意思，不可以單純地從字面上來理解，這樣才不會造成對於關係認知的混淆不清。

8-5 相依 相依關係與關聯關係

8-6 具體化 具體化（Realization）關係是用來表達一個類別之行為是由另一類別來描述定義的，在Java中，它是用implements 來表示。並且，被具體化的類別型態一定是介面（Interface）型態，它是一種特殊的類別型態。具體化關係的表法為一條虛線並且以空心三角形當箭頭指向被具體化的類別，如圖8.34所示。

8-6 具體化 public class ClassA implements interfaceA { // }

本章結束 Q&A討論時間