一、說明
良好的程式結構,有助不但容易閱讀理解,出問題時追蹤問題點也容易。什麼樣才算是良好的結構?其實只要尊守物件導向設計原則,並注意程式的層次性即可。
二、物件導向設計原則(SOLID)
SOLID 是五個物件導向設計原則的縮寫,遵循這些原則可以提高程式的可維護性與擴展性。
- [S]單一功能原則 (Single Responsibility Principle, SRP)
- [O]開閉原則 (Open-Closed Principle, OCP)
- [L]里氏替換原則 (Liskov Substitution Principle, LSP)
- [I]介面隔離原則 (Interface Segregation Principle, ISP)
- [D]依賴反轉原則 (Dependency Inversion Principle, DIP)
單一功能原則 (Single Responsibility Principle, SRP)
定義:一個類別應該只有一個引起它變化的原因,即一個類別只負責一項職責。
說明:當一個類別承擔太多職責時,修改其中一個職責可能影響其他職責。將職責分離可降低耦合度。
案例:
1 | // ❌ 違反 SRP:一個類別處理多個職責 |
開閉原則 (Open-Closed Principle, OCP)
定義:軟體實體應該對擴展開放,對修改封閉。
說明:新增功能時應透過擴展而非修改現有程式碼,避免影響既有功能。
案例:使用介面與繼承實現擴展,而非修改原始類別。
里氏替換原則 (Liskov Substitution Principle, LSP)
定義:子類別必須能夠替換其父類別,且不影響程式正確性。
說明:子類別應該增強而非削弱父類別的功能。
介面隔離原則 (Interface Segregation Principle, ISP)
定義:客戶端不應該依賴它不需要的介面。
說明:應將龐大的介面拆分成更小、更具體的介面,讓客戶端只需知道它需要的方法。
依賴反轉原則 (Dependency Inversion Principle, DIP)
定義:高層模組不應該依賴低層模組,兩者都應該依賴抽象。
說明:依賴介面而非具體實現,可提高程式的靈活性與可測試性。
DRY原則
Don’t repeat yourself (DRY)、Once and only once(OAOO)
是物件導向程式設計中的基本原則,程式設計師的行事準則。旨在軟體開發中,減少重複的資訊。
參考:Wiki 一次且僅一次
KISS原則
Keep It Simple, Stupid (KISS)
KISS 原則是指在設計當中應當注重簡約的原則,而不摻入非必要的複雜性,這樣的系統運作成效會取得最優。
參考:Wiki KISS原則
三、程式的層次性
良好的程式應該有清晰的分層架構,每層負責不同的職責,降低耦合度。
常見分層架構
三層架構 (Three-Tier Architecture)
1 | ┌─────────────────┐ |
各層職責
1. Controller (控制層)
- 接收使用者請求
- 驗證輸入參數
- 呼叫 Service 處理業務邏輯
- 回傳結果給 View
2. Service (服務層/業務邏輯層)
- 處理業務邏輯
- 協調多個 Repository
- 處理交易 (Transaction)
- 不應包含資料庫操作細節
3. Repository (資料存取層)
- 封裝資料庫操作
- 提供資料的 CRUD 方法
- 隱藏資料來源細節(可能是資料庫、API、快取等)
4. Model (資料模型層)
- 定義資料結構
- 資料驗證規則
- 業務規則
實例說明
Controller 層
1 | // Controller:處理 HTTP 請求 |
Service 層
1 | // Service:業務邏輯 |
Repository 層
1 | // Repository:資料存取 |
Model 層
1 | // Model:資料庫存取 |
分層的優點
- 關注點分離:每層專注於自己的職責
- 易於測試:可獨立測試各層
- 易於維護:修改某層不影響其他層
- 可重用性:Service 可被多個 Controller 使用