系統設計筆記 - 軟體服務

移幣

發佈於AI agent 與系統設計

更新於 2025/03/15發佈於 2025/02/28閱讀時間約 9 分鐘

English version:

_{英文版在 hackmd}

本文包涵：

物件導向的 SOLID 設計原則
常見系統設計模式

物件導向的 SOLID 設計原則

以物件導向 (Object-oriented programming, OOP)設計程式時，常遵循 SOLID 原則：

S: 單一職責原則 (Single responsibility principle)：一模組一功能

每個模組 (module)或類別 (class)只做一件事，利於維護與測試

例如：處理登入模組，不該出現結帳功能 (白話：菜刀不兼鍋鏟職)

O: 開放封閉原則 (Open-closed principle)：新需求新模組

程式碼應對「擴展」開放，對「修改」封閉

例如：想增加登入驗證，應「另建模組」，而非「直些修改舊模組」

L: 里氏替換原則 (Liskov substitution principle)：子類別替代父類別，程式功能應不變

後代需具備祖先的所有特徵

例如：卡車屬於車，但車不一定是卡車 (卡車有輪胎、引擎等一切車子應有的組件，但「車」不只有卡車一種)

若你想開卡車去旅行，它當然能勝任 (旅遊品質是另一回事)

敞篷車、轎車、卡車都能稱作車，所以都能代步 (功能不變)

^{圖源：移幣，i.e. 我}

I: 介面隔離原則 (Interface segregation principle)：不相關的功能就丟掉

不應強迫用戶實作不會用到的功能

例如：我只想 掃描 文件，使用 印表機 介面時，就不該強迫我使用 列印 功能

D: 依賴反轉原則 (Dependency inversion principle)：改動低階模組不應影響高階者

高階模組不依賴低階模組，而應依賴抽象 (Abstraction)，低階模組實作抽象

例如：電視遙控器 (低階)壞了，只需要再買一個，不用連電視 (高階)都換掉

因為電視不依賴遙控器，兩者依賴特定訊號協定 (抽象)

SOLID 只是指導原則，設計仍保有高度彈性

有基本概念後，就來看看常見的設計模式吧！

常見設計模式

先看統整再細說：

常見設計模式總覽

^{製表人：我自己}

原型 (Prototype pattern)

先做出樣品，再靠複製來生產物件 (樣品＝原型＝模板)

好處是：
- 效率高

做過報告就知道，複製貼上比從頭打字快多了

- 容易管理

想更新產品，只需修改模板

範例：
- Ctrl + C → Ctrl + V

當然不會這麼爛XD

- 「用履歷模板」就是個常見案例，因為「複製」了模板，並對其進行修改

原型 (Prototype)：套模生產

^{圖源：又是我}

單例 (Singleton)

一類別 (class)一實例 (instance)，並提供全域存取點

優點：
- 資源共享

全域存取點共用，即同個資源池大家分

- 實例化效率高

實例化 (instantiation)時，物件才取得資源。所以若只需實例化一次，就不需要不斷獲取資源 (想像不斷開關冷氣 vs 開著冷氣，前者更耗電)

- 管理方便

所有人 (或物件)都需從全域存取點獲得服務，則只需管理該存取點，不必為每個終端 (使用者/物件)個別服務

範例：
- 資料庫連線池 (connection pool)

這是個經典案例，若每個用戶訪問時，都需取得資料庫連線、用完再關閉，會很耗資源

反之，先取得一堆連線 (i.e. 連線「池」)，使用者訪問時分配一個給他，用完再丟回池中，後者較省資源

- 日誌管理系統 (Log system)

電腦只需一個日誌管理員，處理各種系統日誌

- 設定檔管理員

各程式可有獨立設定檔，但讀取可用同個管理員

- 政府機關

這應該最好理解。不會因為你我都要辦護照，政府就生出兩個外交部。

「政府」即為類別 (class)，「外交部實體」便是實例 (instance)

然而，單例有些缺點：
- 違背 SOLID 的「單一職責原則 (Single responsibility principle)」
- 高耦合性 (所有東西都掛在一起)

→ 不利單元測試 (unit test)

→ 修改局部程式碼，可能影響其他功能 (牽一髮動全身)

- 全域變數污染 (global variable corruption)

全域存取點即為全域變數

- Multi-Thread(多執行緒，亦稱多線程) 問題

若程式沒特別處理，每個執行緒都會產生實例

→ 可藉雙重檢查鎖定 (Double-Checked Locking Pattern，又稱「鎖暗示 (lock hint)」)解決 --- 非本文重點，故不在此贅述

單例模式 (Singleton)：一類別一實例，開給全域存取

^{圖源：還是我}

工廠模式 (Factory Pattern)

製程與使用分離，i.e. 終端使用者毋需瞭解生產過程，~~出張嘴~~下單就好

工廠的功能便是製造產品，此「產品」即為物件 (object)
靠抽象 (abstraction)隔離製程
使用者只需實例化物件，至於物件怎麼產出的，不必在乎 (通常也無法得知)
優點：
- 高靈活性

生產新品時，不必修改上下游程式碼

- 易維護

工廠程式碼改不到，所以有問題一定是你的問題

- 乾淨程式碼 (Code clarity)
範例：
- 做披薩

還記得上次訂披薩的流程嗎？看菜單 → 下單 → 取貨 → 享用

裡面可有個步驟，需要知道披薩製作過程？

除非你是廚師，否則一般人吃 100 次披薩，也不會掌握製作細節

- - 披薩餐廳就是工廠
  - 客人是使用者
  - 披薩是物件
- 汽車工廠

同理，買車時僅需選輛買得起、好看、實用的車，我哪管車怎麼蹦出來的？

- - 工廠，嗯，就是工廠
  - 買家是使用者
  - 汽車是物件

抽象工廠 (Abstract Factory Pattern)

造工廠的藍圖，亦即工廠的工廠

製作相關工廠前，不須指定具體類別 (class)
關係：抽象工廠
- 工廠
- - 物件
範例：
- 圖形化介面設計藍圖 → 抽象工廠
- 給 Windows 的圖形化介面 → 工廠
- - 介面上的按鈕 → 物件
- 給 Mac 的圖形化介面 → 工廠
- - 介面上的按鈕 → 物件

製造者模式 (Builder Pattern)

製程各步驟拆開，由不同製造者 (builder)負責

作法：一步驟一製造者，製造者僅負責份內工作
好處：
- 解決複雜問題

大工程拆成小任務，自然容易許多

- 避免跨度建構函式 (telescoping constructors)

有種情況是，一個類別 (class)為了接不同數量的參數 (parameter)，而建立多個建構函式 (constructors)，屬於一種反面模式 (anti-pattern)，設計上應避免

製造者模式 (Builder pattern)：拆分製造程序，各步驟由一個製造者負責

^{圖源：仍是我}~~^{How old am I? 怎麼老是我}~~

依賴性注入 (Dependency Injection Pattern)

模組 (module)或類別 (class)應外包「所需」功能，而非自產自銷

名詞解釋：
- 依賴性 (Dependency)：做某件事所需的東西

車靠引擎跑 → 車依賴引擎

- 注入 (Injection)：從外部給予某物

為手機「裝」電池，而非把電池做在手機上~~，如同現代無良手機品牌們~~

→ 將電池注入手機

優點：
- 低耦合度 (loose coupling)
- 高靈活性 (Flexibility)
- 容易測試
- 乾淨程式碼 (clean code)

依賴性注入 (Dependency Injection Pattern)：外包功能，而非自產自銷

^{圖源：當然，只會是我}

最後，來看看軟體服務常用的設計形式

軟體服務設計模式

三層式架構 (3-tier architecture)

服務拆三層：使用者 - 伺服器 - 資料庫

3層式架構 (3-tier architercture)：用戶端 - 伺服器端 - 資料庫端

^{圖源：不是我還會是誰？}

哪三層？
- 展示層 (presentation tier)：顯示給使用者的門面 (前端)
- 商業邏輯層 (business logic tier)：處理核心要務 (伺服器後端)
- 資料存取層 (Data access tier)：資料取用、存儲 (資料庫)
好處？
- 關注點分離 (Separation of Concerns) → 更好維護
- 高可擴展性 (Scalability)
- 安全性高
- 可重用性
- 解耦 (Decoupling)