メインコンテンツまでスキップ

Class Diagram 範本

用途：OOP 類別結構、繼承關係、Interface 實作

適用場景：

  • 「這組類別怎麼繼承」
  • 「哪些 class 實作哪個 interface」
  • 「Design Pattern 結構」

範本 1：基本繼承​

關鍵符號：

  • <|-- 繼承（inheritance）
  • *-- 組合（composition）— 強依賴，生命週期綁定
  • o-- 聚合（aggregation）— 弱依賴
  • --> 關聯（association）
  • ..> 依賴（dependency）
  • ..|> 實作介面

範本 2：Interface + 實作​

關鍵：

  • <<interface>> stereotype 標記介面
  • &lt;|.. 虛線（實作介面）
  • &lt;|-- 實線（繼承類別）

範本 3：Composition / Aggregation​

關鍵：

  • *-- 組合（Equipment 被刪除時 Variables 也不存在）
  • --> 關聯（Equipment has a State）
  • <<enumeration>> 標記列舉
  • List~T~ 泛型寫法

範本 4：Design Pattern（Strategy Pattern）​

使用時機：展示 design pattern、說明重構後的架構。

範本 5：C# 特有（Properties / Methods）​

C# 慣例：

  • _ 前綴：private field
  • PascalCase：public property/method
  • 冒號後的型別：Property
  • 括號：Method

Access Modifier 符號​

符號意義
+public
-private
#protected
~package/internal

客製化指南​

要標什麼屬性​

必標：

  • public API（方法、屬性）
  • 重要的 field（尤其 state）
  • 泛型參數

不必標（避免圖太雜）：

  • Constructor（除非需特別說明）
  • Getters/Setters 自動產生的
  • Override 類常見方法（ToString、Equals）

類別數量​

  • 單一圖 5-10 class 最佳
  • 超過 10 → 拆成多張，按 package / namespace 分

何時用 classDiagram vs 其他​

情境用 class用其他
OOP 類別結構✅—
Design pattern 說明✅—
服務 / 模組架構❌flowchart
DB schema❌erDiagram
純 function / module🟡可能用 flowchart 更好

Real-world 範例建議​

GST Framework 核心可參考：

  • IEquipment / Equipment（base + implementation）
  • ITransport / SerialTransport / TcpTransport
  • RecipeEngine + State Pattern

Anti-patterns​

❌ 沒寫 access modifier​

class User {
    id
    email
    getName()
}

應該是：

class User {
    -uuid id
    -string email
    +getName() string
}

❌ 所有關係都用 -->​

A --> B
A --> C
A --> D

搞不清楚是繼承、實作、聚合還是組合。用正確符號：

A <|-- B     (B 繼承 A)
A <|.. C     (C 實作 A)
A *-- D      (A 包含 D)

❌ 圖超過 15 class​

拆成多張，按 子系統 分組。