JavaScript 設計模式筆記 - SOLID 原則與 Vue.js 應用

🌐 日本語版

📅 2025年11月6日

javascriptdesign-patternssolidvue

2024 年初參加了一場 JavaScript 設計模式的讀書會，主題是討論 Addy Osmani 的《JavaScript 設計模式學習手冊》。 最近在重建部落格時，想起這場讀書會還沒留下點什麼紀錄有些可惜， 而且這種主題沒有時效問題，就決定趁這個機會整理一下當時的內容，順便 水一篇 分享給大家。

我負責的是最初的導讀，所以說雖然 Addy Osmani 書中是以 React 為例，但由於我的私心 (笑) 就盡量用我最熟悉的 Vue.js 的觀點來說明設計模式的概念與應用。

這篇文章整理了當時讀書會的重點內容，包含設計模式的基本概念、SOLID 原則，以及一些常見設計模式在 Vue.js 中的應用。

對於開發者來說，設計模式一直是個既熟悉又陌生的主題，說熟悉，是因為我們可能每天都在用；陌生，是因為用的時候你可能不一定知道自己正在用。

---

為什麼要學設計模式？

Good code is like a love letter to the next developer who will maintain it! 好的程式碼就像寫給下一個維護它的開發人員的情書！ — Addy Osmani

這句話真的很經典。每次接手別人的專案，都希望看到的是「祖產豪宅」，結果往往是「危樓廢墟」。 設計模式就是幫助我們寫出好維護、好擴充程式碼的工具。

設計模式的好處：

• 容易增減功能
• 容易維護
• 容易重複使用程式碼
• 團隊合作時更容易溝通與分工

但也要小心過度使用：

• 過度複雜，讓其他開發者難以理解
• 過度設計（Over-engineering）
• 選擇了不適合的設計模式

---

設計模式是什麼？

根據 Wikipedia 的定義：

在軟體工程中，軟體設計模式是在軟體設計的給定上下文中，針對普遍問題的一種通用且可重用的解決方案。

簡單來說：「有些人已經解決你的問題了！」

設計模式是一套解決程式設計問題的通用解決方案集合。它們：

• 是一種抽象的模板，可以用於不同的情況和程式語言
• 跟演算法有點像，但更偏向解決架構層面的問題
• 一再重複出現的東西、事件、現象，就稱為「模式」
• 你也可以建立自己的設計模式，只要它能解決問題並且能夠被重複使用

經典的 GoF

1995 年由四位作者（Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides）出版的《Design Patterns》被譽為「軟體工程師的聖經」。 書中提出 23 種經典設計模式，這四位作者也因此被稱為 GoF (Gang of Four)。

設計模式的三大類別：

1. 建立型模式（Creational Patterns） - 用於物件的創建

   • 工廠模式、抽象工廠模式、單例模式、建造者模式、原型模式

2. 結構型模式（Structural Patterns） - 用於表示物件組合

   • 適配器模式、橋接模式、組合模式、裝飾者模式、外觀模式、享元模式、代理模式

3. 行為型模式（Behavioral Patterns） - 用於物件之間的通訊

   • 責任鏈模式、命令模式、解釋器模式、迭代器模式、中介者模式、備忘錄模式、觀察者模式、狀態模式、策略模式、模板方法模式、訪問者模式

---

反模式（Anti-Pattern）

反模式就像是一種模式，只不過它提供的不是解決方案，而是表面上看起來像解決方案但實際上不是解決方案的東西。

為什麼會產生反模式？

• 經驗不足：不了解更好的做法
• 時間壓力：趕著上線，先求有再求好
• 誤用設計模式：把設計模式用在不適合的地方
• 過度設計：為了用而用，反而把簡單問題複雜化

反模式比不用設計模式更危險，因為它會讓程式碼品質下降，增加維護成本。有時候反模式會被誤認為是設計模式，這是最危險的情況。

JavaScript 常見的反模式

1. 污染全域命名空間

// ❌ 反模式：所有變數都在全域
var name = 'John'
var age = 30
var email = 'john@example.com'

// ✅ 好的做法：使用模組或 IIFE
const user = {
  name: 'John',
  age: 30,
  email: 'john@example.com'
}

2. 將字串傳給 setTimeout/setInterval

// ❌ 反模式：會觸發 eval()，不安全且效能差
setTimeout("console.log('這是不安全的！')", 1000)

// ✅ 好的做法：傳遞函數
setTimeout(() => console.log('這是安全的！'), 1000)

3. 修改內建原型

// ❌ 反模式：修改 Array.prototype
Array.prototype.first = function() {
  return this[0]
}

// ✅ 好的做法：使用工具函數
function getFirst(arr) {
  return arr[0]
}

4. 不使用嚴格模式

// ❌ 反模式：沒有 'use strict'，容易出錯
function calculateTotal() {
  totle = 100  // 拼錯了，但不會報錯，變成全域變數
}

// ✅ 好的做法：啟用嚴格模式
'use strict'
function calculateTotal() {
  const total = 100  // 拼錯會立即報錯
}

5. Callback Hell

// ❌ 反模式：多層嵌套的回呼
getData(function(a) {
  getMoreData(a, function(b) {
    getMoreData(b, function(c) {
      console.log(c)
    })
  })
})

// ✅ 好的做法：使用 Promise 或 async/await
async function fetchData() {
  const a = await getData()
  const b = await getMoreData(a)
  const c = await getMoreData(b)
  console.log(c)
}

如何避免反模式？

1. 持續學習：了解最新的 Best Practices
2. 程式碼審查：讓團隊成員互相 Review 程式碼
3. 使用 Linter：透過工具自動檢查常見問題
4. 寫測試：好的測試能暴露設計問題，提高程式碼品質
5. 重構：定期重構程式碼，改善設計，避免累積技術債

---

JavaScript 的模組化

早期的 JavaScript 是沒有模組化概念的，歷經多年演進：

1. IIFE（即時函數） - 利用閉包封裝模組，形成私有空間
2. CommonJS - Node.js 出現後的模組規範
3. AMD（Asynchronous Module Definition） - 非同步模組定義
4. UMD（Universal Module Definition） - 通用模組定義
5. ES6 Modules - 現代 JavaScript 的模組化標準（import / export）

如今結合 Vite、Webpack、Rollup 等打包工具，可以進行靜態分析和 Tree Shaking，讓 JavaScript 的模組化更加完善。

---

SOLID 原則

遵守這些原則，就算不懂設計模式，也能寫出好的程式碼。

1. SRP - 單一職責原則（Single Responsibility Principle）

一個 Class 只負責一項職責

在 Vue.js 中：

• 將不同的功能分割到不同的元件中
• 確保每個元件只處理一個任務
• 提高元件的重用性

範例：

假設有個購物車頁面，不應該把所有功能塞在同一個元件：

<!-- ❌ 違反 SRP：一個元件做太多事 -->
<template>
  <div>
    <div>商品列表、價格計算、結帳按鈕、優惠券輸入...</div>
  </div>
</template>

<!-- ✅ 符合 SRP：拆分成多個元件 -->
<CartItemList />      <!-- 只負責顯示商品列表 -->
<CartSummary />       <!-- 只負責計算總價 -->
<CouponInput />       <!-- 只負責優惠券處理 -->
<CheckoutButton />    <!-- 只負責結帳按鈕 -->

2. OCP - 開放封閉原則（Open/Closed Principle）

對於擴展是開放的，對於修改是封閉的

能夠在不改變現有程式碼的情況下擴展元件的行為。

在 Vue.js 中：

• 使用 slots 擴展元件功能
• 使用 composables（推薦）來封裝可重用的邏輯
• 避免使用 mixins（已不推薦）

範例：

使用 slot 讓元件可以擴展，而不需要修改原始元件：

<!-- ❌ 違反 OCP：每次新增需求都要改元件 -->
<Button v-if="type === 'primary'" class="btn-primary">送出</Button>
<Button v-else-if="type === 'danger'" class="btn-danger">刪除</Button>
<!-- 每次新增按鈕類型都要改這裡 -->

<!-- ✅ 符合 OCP：用 slot 擴展 -->
<Button>
  <template #icon><IconPlus /></template>
  新增項目
</Button>
<!-- 可以自由擴展內容，不用改 Button 元件 -->

3. LSP - 里氏替換原則（Liskov Substitution Principle）

子類應該能夠替換它們的基類而不影響程式的正確性

若使用 TypeScript，可定義共同的 PaymentMethod 介面，以確保所有支付策略都遵守相同結構。 (這裡的共同介面相當於 TypeScript 的 interface)

在 Vue.js 中：

• 子類別物件（具體策略）可以在程式中取代其父類別物件（策略介面）
• 新增商品處理邏輯（新的策略）變得更加簡單，無需修改現有的元件邏輯

範例：

不同的支付方式應該可以互換使用：

// 所有支付方式都有相同的介面
const paymentMethods = {
  creditCard: { pay: (amount) => { /* 信用卡支付 */ } },
  cash: { pay: (amount) => { /* 現金支付 */ } },
  linePay: { pay: (amount) => { /* LINE Pay 支付 */ } }
}

// 可以自由切換，不影響程式運作
function checkout(method, amount) {
  method.pay(amount)  // 不管哪種支付方式，都能正常運作
}

4. ISP - 介面隔離原則（Interface Segregation Principle）

一個 Class（元件）不應該被強迫用到它不需要的方法

在 Vue.js 中：

• 設計細粒度的 props 和事件
• 確保元件不會被迫接收它們不需要的屬性或方法
• 提高元件的獨立性和重用性

範例：

不要傳遞整個巨大的物件，只傳需要的屬性：

<!-- ❌ 違反 ISP：傳整個 user 物件 -->
<UserCard :user="user" />
<!-- UserCard 可能只需要 name 和 avatar，卻被迫接收整個 user -->

<!-- ✅ 符合 ISP：只傳需要的屬性 -->
<UserCard
  :name="user.name"
  :avatar="user.avatar"
/>
<!-- 元件只接收它真正需要的資料 -->

5. DIP - 依賴反轉原則（Dependency Inversion Principle）

高階模組不該相依於低階模組，兩者都應該相依於抽象

白話：不要把程式碼寫死在某種實作上

在 Vue.js 中：

• 元件不直接管理狀態，而是透過 Pinia store 來管理
• 互動的部份交給抽象類別或介面，會改變的實作放到子類別裡面
• 未來需求改變，只需要修改 store 的實作，而不需要修改使用的元件

範例：

元件不直接處理資料，而是相依於抽象的 store：

<!-- ❌ 違反 DIP：元件直接處理 API 和資料 -->
<script setup>
const products = ref([])
const fetchProducts = async () => {
  const res = await fetch('/api/products')  // 寫死實作
  products.value = await res.json()
}
</script>

<!-- ✅ 符合 DIP：相依於抽象的 store -->
<script setup>
import { useProductStore } from '@/stores/product'
const productStore = useProductStore()
// 元件不知道資料怎麼來，只知道透過 store 取得
// 未來改用 GraphQL 或其他方式，元件不用改
</script>

---

其他常見的設計模式

以下是幾個在 Vue.js 中常見的設計模式：

1. 觀察者模式（Observer Pattern）

當一個狀態改變時，所有相依於它的目標都會得到通知並自動更新。

Vue.js 的響應式系統本質上就是一種觀察者模式的實現。當狀態變化時，Vue.js 會自動更新 DOM。

2. 代理模式（Proxy Pattern）

為其他物件提供一種代理以控制對這個物件的存取。

Vue 3 的 reactive 就是一種代理模式的實現，使用 JavaScript 的 Proxy API 來追蹤狀態變化。

3. Module 模式

用來模擬類別的私有成員，並且可以將公開的成員封裝在閉包中。

Vuex 或 Pinia 結合了 Module、Observer 與 Singleton 模式，用以實作集中式的狀態管理。

4. 工廠方法模式（Factory Method Pattern）

在不直接調用構造函數的情況下建立物件。

在 Vue.js 中，可透過 Props 或 Attr 來決定要渲染的元件、樣式等：

<component :is="currentView" />

<component :is> 屬於 Vue 的動態元件機制，本質是透過工廠方法的概念實現動態建立與切換元件。 根據不同條件動態切換元件，這就是工廠模式在 Vue.js 的應用。

5. 單例模式（Singleton Pattern）

確保一個類別只有一個實例，並且讓全域都能存取。

全域狀態管理（如 Pinia store）就是單例模式的典型應用，確保整個應用程式共享同一個狀態實例。

6. 策略模式（Strategy Pattern）

定義一系列的算法，把它們一個個封裝起來，並且使它們可以互相替換。

例如表單驗證時，可以定義多種驗證策略（email 驗證、長度驗證、必填驗證等），根據需求組合使用。

7. 命令模式（Command Pattern）

將請求封裝為物件，藉由不同的請求來參數化其他物件。

常見於實作 Undo/Redo 功能，將每個操作封裝成命令物件，就能輕鬆實現這類功能。

8. 責任鏈模式（Chain of Responsibility Pattern）

使多個物件都有機會處理請求，從而避免請求的發送者和接收者之間的耦合關係。

例如一連串的驗證規則，按順序對輸入進行驗證，直到某規則回傳驗證失敗，或者所有條件都通過。

---

複合模式

實務上分析需求時，常常會發現要同時結合多種模式才能解決問題。

• 不見得一個問題只能用一種模式
• 分析需求時，通常會發現要結合多個模式才能解決問題
• 有些模式是多個基本模式所結合出來的，就被稱為複合模式
• 例如傳統 MVC 就會用到 Strategy 模式、Observer 模式、Composite 模式等

---

總結

整理完這篇筆記，回想當時讀書會的討論，最大的收穫不是記住了多少種設計模式，而是理解了「為什麼要用」比「怎麼用」更重要。

設計模式不是銀彈，也不是炫技的工具，它最大的價值在於：

1. 提供共通的語言 - 跟同事說「這裡用觀察者模式」，大家立刻知道你在講什麼
2. 前人的經驗總結 - 避免重蹈覆轍，站在巨人的肩膀上
3. 幫助思考架構 - 面對複雜問題時，有個思考的框架

但要記住幾個重點：

• 先求簡單： 不要為了用設計模式而用，先解決問題再說
• 遵守 SOLID：就算不懂設計模式，遵守 SOLID 原則也能寫出好程式碼
• 避免過度設計： 過早最佳化 (Premature Optimization) 是萬惡的根源
• 別被名詞困住：看到自己寫的程式碼符合某個模式的精神，恭喜你已經在用了!

給想學設計模式的朋友：

1. 不用急著全部記起來，先從常用的開始（觀察者、工廠、單例）
2. 在實際專案中練習，看到問題自然會想到對應的模式
3. 多看別人的程式碼，尤其是開源專案（Vue、React 等框架的原始碼都是設計模式的寶庫）
4. 持續重構，設計模式不是一次到位，而是持續改進的過程

最後，寫程式跟寫文章一樣，重點是讓讀者（包含未來的自己）容易理解。設計模式是幫助我們達成這個目標的工具，而不是目標本身。

---

相關資源：

• JavaScript 設計模式學習手冊
• Vue.js 官方文件
• Pinia 官方文件