物件導向分析(OOA, Object-Oriented Analysis)

TL;DR

OOA 是「需求分析」的 OO 視角:把使用者需求拆解成 物件(類別、屬性、關係、行為),作為設計階段的橋樑。分析「有什麼東西、它們長怎樣、彼此怎麼互動」,還沒到「怎麼實作」的層級(那是 OOD)。

OOA 是做什麼

需求 → [OOA 分析] → 物件模型 → [OOD 設計] → 程式碼藍圖 → 實作
              ↑                       ↑
        本篇講這個              下一站見

OOA 關注「世界是由什麼組成的」:

• 識別 entity(物件 / 類別)
• 找出 關係(繼承、聚合、依賴)
• 列出 屬性(物件持有的資料)
• 描述 行為(物件能做的事)

結果通常是 UML 類別圖、序列圖、用例圖,還沒寫一行 code。

五個層次(Coad-Yourdon 方法)

五個活動

1. 標識物件類 — 從需求中找出名詞 → 候選類別
2. 標識結構 — 找出 has-a / is-a 關係
3. 定義主題 — 把相關類別歸成主題群組
4. 定義屬性 — 每個類別需要哪些 state
5. 定義服務 — 每個類別暴露哪些方法

怎麼分析(實務步驟)

1. 將使用者需求 → 抽象 ==類別 / 介面==
2. 用 ==資料流向== 描述各類別之間的互動
3. 定義 ==屬性==(state、constants)
4. 定義 ==方法==(method)

簡單口訣:找名詞 → 找關係 → 找資料 → 找動作。

範例:電商系統 OOA

需求

「使用者可以瀏覽商品、加入購物車、下單、付款。商家可以管理庫存。」

候選類別(從名詞抓)

User / Product / Cart / Order / Payment / Merchant / Inventory

主題分組

結構(關係)

User ──┬─ owns ─→ Cart ─ contains ─→ CartItem ─ refs ─→ Product
       └─ creates ─→ Order ─ contains ─→ OrderItem ─ refs ─→ Product
                       │
                       └─ paid by ─→ Payment

Merchant ─ owns ─→ Product ─ tracked by ─→ Inventory

屬性(從需求 + 常識推)

User { id, name, email, address }
Product { sku, title, price, stock, merchantId }
Cart { userId, items[] }
CartItem { productId, quantity }
Order { id, userId, items[], total, status, createdAt }
Payment { orderId, amount, method, status }

服務(每個類別 method)

User: register(), login(), updateProfile()
Cart: addItem(), removeItem(), checkout()
Order: place(), cancel(), refund()
Payment: process(), verify()
Inventory: deduct(), restock()

這就是 OOA 的產物:一份「世界觀模型」,還沒到實作。

OOA vs OOD vs OOP

現代敏捷開發中三者界線模糊,常常邊寫邊重構。但對 大型新專案 / 跨團隊協作,先 OOA 拉清楚 entity 模型仍然是值得的。

現代視角:DDD(Domain-Driven Design)

OOA 在 2010 年後 被 DDD(Domain-Driven Design) 大幅吸收 + 進化:

DDD 把 OOA 升級成更貼近業務的方法論,實務上更有效。OOA 概念仍是 DDD 的基礎,值得理解。

在前端的應用

OOA 不只後端用,前端也適用:

// 從需求「使用者可以收藏文章」推導
class User {
  id: string;
  bookmarks: Bookmark[];
  bookmark(post: Post) { /* ... */ }
}

class Post {
  id: string;
  title: string;
  author: User;
}

class Bookmark {
  userId: string;
  postId: string;
  createdAt: Date;
}

這個 OOA 結果可以直接對應到 React state 設計、Firestore schema、API endpoint。

前端也該做 OOA

不是只有「後端工程師才需要 entity model」。前端寫 React 時,如果 component / state 散亂沒模型,後期維護會很痛。先想清楚 entity → 自然知道 component 怎麼切。