開閉原則（OCP）在 Java 設計模式中的應用與實戰

定義

軟體實體（類、模組、函數）應對擴展開放，對修改關閉。

意指：新增功能通過擴展（繼承、實現介面、組合）實現，而非修改既有代碼。

核心價值

1. 測試穩定：原有測試碼無需修改，僅測試新增部分。
2. 復用性高：邏輯以原子單元組合，顆粒度越細復用越強。
3. 可維護性強：符合面向對象設計，降低耦合。

違反 OCP 反例：圖形編輯器

class GraphicEditor {
    public void drawShape(Shape s) {
        if (s.type == 1) drawRectangle(s);
        else if (s.type == 2) drawCircle(s);
        // 新增形狀必須修改此類 → 違反 OCP
    }
}
class Shape { int type; }
class Rectangle extends Shape { Rectangle() { type = 1; } }
class Circle extends Shape { Circle() { type = 2; } }

符合 OCP 改造：多態分派

abstract class Shape {
    abstract void draw(); // 契約
}
class Rectangle extends Shape {
    public void draw() { /* 畫矩形 */ }
}
class Circle extends Shape {
    public void draw() { /* 畫圓 */ }
}

class GraphicEditor {
    public void drawShape(Shape s) { s.draw(); } // 永不修改
}

新增三角形只需新增 Triangle extends Shape，GraphicEditor 零修改。

四大落地策略

1. 抽象約束：
   • 介面/抽象類定義邊界，禁止在實現類新增 public 方法。
   • 參數、引用類型盡量用介面/抽象類。
   • 抽象層一旦穩定，嚴禁修改。
2. 元數據驅動：
   • 配置檔、資料庫、註解驅動行為（如 Spring @Autowired、路由配置）。
   • 控制反轉（IoC）容器是極致體現。
3. 專案公約：
   • 團隊統一命名、分層、異常處理、日誌規範等公約優於配置。
4. 封裝變化：
   • 相同變化封裝到同一介面；不同變化拆分到不同介面，避免「神介面」。

OCP 與設計模式的關係

絕大多數設計模式（策略、模板方法、裝飾者、觀察者、工廠、適配器……）都是為了在不同維度滿足 OCP。

總結

1. OCP 是架構穩定與擴展性的基石。
2. 關鍵在於識別系統的「變化點」，用抽象隔離變化。
3. 現實中「完全關閉修改」不可能，但應將修改限制在低層、高穩定模組，高層業務邏輯僅通過擴展變化。