DesignPattern on Bill.Lin's Notes

Memento — 不破壞封裝的快照與復原

Tue, 07 Aug 2018 22:39:01 +0800

1. 意圖

在不破壞封裝的前提下，擷取並儲存物件的內部狀態，並能在稍後將物件恢復至該狀態。

2. UML 類圖

classDiagram
    class Originator {
        -state String
        +save() Memento
        +restore(Memento)
    }
    class Memento {
        -state String
        +getState() String
    }
    class Caretaker {
        -history Deque~Memento~
        +backup(Originator)
        +undo(Originator)
    }
    Originator --> Memento : creates
    Caretaker --> Memento : stores
    Caretaker --> Originator

3. 何時用 / 何時別用

用：

需要 undo/redo（文字編輯器、繪圖工具、棋局）
交易 savepoint：資料庫 JTA rollback、遊戲存檔
需要「時光機」式還原，但又不想讓外部直接存取物件欄位

別用：

狀態物件很大（大量圖片、深層 object graph），每次快照記憶體開銷不可接受
外部已有持久化機制（DB、Redis）可直接記錄版本，不需再包一層
狀態欄位非常簡單，直接暴露欄位或用 Builder 更清楚

4. Java 範例

使用 Java record 作為不可變快照（Java 16+）：

Interpreter — 為語言定義文法與解釋器

Tue, 07 Aug 2018 22:38:42 +0800

1. 意圖

為一個語言定義文法表示，並提供解釋器來處理該文法的句子（AST 節點遞迴求值）。

2. UML 類圖

classDiagram
    class Expression {
        <>
        +interpret(Context) int
    }
    class NumberExpression {
        -value int
        +interpret(Context) int
    }
    class AddExpression {
        -left Expression
        -right Expression
        +interpret(Context) int
    }
    class SubtractExpression {
        -left Expression
        -right Expression
        +interpret(Context) int
    }
    Expression <|.. NumberExpression
    Expression <|.. AddExpression
    Expression <|.. SubtractExpression
    AddExpression --> Expression : left
    AddExpression --> Expression : right
    SubtractExpression --> Expression : left
    SubtractExpression --> Expression : right

3. 何時用 / 何時別用

用：

Iterator — 迭代器模式

Tue, 07 Aug 2018 22:38:21 +0800

1. 意圖

提供一種方式，讓外部程式碼可依序存取聚合物件的元素，而不需要知道其底層結構。

2. UML 類圖

classDiagram
    class Iterable~T~ {
        <>
        +iterator() Iterator~T~
    }
    class Iterator~T~ {
        <>
        +hasNext() boolean
        +next() T
        +remove()
    }
    class ConcreteCollection {
        -elements List~T~
        +iterator() Iterator~T~
    }
    class ConcreteIterator {
        -index int
        +hasNext() boolean
        +next() T
    }
    Iterable <|.. ConcreteCollection
    Iterator <|.. ConcreteIterator
    ConcreteCollection --> ConcreteIterator : creates

3. 何時用 / 何時別用

用：

需要為自訂資料結構（樹、圖、分頁資料）提供統一遍歷介面
需要支援多種遍歷方式（正序、逆序、層序）
想讓自訂集合可用 enhanced for-loop（只需實作 Iterable）

別用：

直接使用 JDK 集合時，Stream 通常比自訂 Iterator 更簡潔
資料集合固定且簡單，直接 index 迴圈反而更直覺

4. Java 範例

// 自訂範圍迭代器，避免 int[] 陣列浪費記憶體
public class Range implements Iterable<Integer> {
    private final int start;
    private final int end;   // exclusive

    public Range(int start, int end) {
        this.start = start;
        this.end   = end;
    }

    @Override
    public Iterator<Integer> iterator() {
        return new Iterator<>() {
            private int current = start;

            @Override public boolean hasNext() { return current < end; }
            @Override public Integer next() {
                if (!hasNext()) throw new NoSuchElementException();
                return current++;
            }
        };
    }
}

// 使用 enhanced for-loop
for (int n : new Range(1, 6)) {
    System.out.print(n + " "); // 1 2 3 4 5
}

// 轉成 Stream
StreamSupport.stream(new Range(1, 6).spliterator(), false)
    .filter(n -> n % 2 == 0)
    .forEach(System.out::println); // 2 4

5. JDK / Spring 真實案例

java.util.Iterator<T> + Iterable<T>：所有 JDK 集合實作 Iterable，enhanced for-loop 底層即呼叫 iterator()。這就是 Iterator Pattern 的標準 Java 實作。

Visitor — 將演算法從物件結構抽離

Tue, 07 Aug 2018 22:38:06 +0800

1. 意圖

在不修改物件結構的前提下，將新操作以獨立的 Visitor 類加入，透過雙分派（double dispatch）實現型別安全的呼叫。

2. UML 類圖

classDiagram
    class Visitor {
        <>
        +visitCircle(Circle)
        +visitRectangle(Rectangle)
    }
    class Shape {
        <>
        +accept(Visitor)
    }
    class Circle {
        -radius double
        +accept(Visitor)
    }
    class Rectangle {
        -width double
        -height double
        +accept(Visitor)
    }
    class AreaCalculator {
        +visitCircle(Circle)
        +visitRectangle(Rectangle)
    }
    Visitor <|.. AreaCalculator
    Shape <|.. Circle
    Shape <|.. Rectangle
    Circle --> Visitor : accept
    Rectangle --> Visitor : accept

3. 何時用 / 何時別用

用：

物件結構穩定，但需要頻繁新增對元素的操作（如 AST 有新的 code generation pass）
同一物件結構需要多種不相關的操作（計算面積、序列化、驗證）
不想把所有操作塞進元素類，保持高內聚

別用：

State — 讓物件隨狀態改變行為

Tue, 07 Aug 2018 22:37:58 +0800

1. 意圖

讓物件在其內部狀態改變時自動改變行為，看起來就像換了一個類別。

2. UML 類圖

classDiagram
    class Context {
        -state State
        +setState(State)
        +request()
    }
    class State {
        <>
        +handle(Context)
    }
    class ConcreteStateA {
        +handle(Context)
    }
    class ConcreteStateB {
        +handle(Context)
    }
    Context --> State
    State <|.. ConcreteStateA
    State <|.. ConcreteStateB

3. 何時用 / 何時別用

用：

物件行為取決於狀態，且狀態在執行期變化
存在大量以狀態為條件的 switch / if-else
狀態轉換規則複雜，不同狀態下允許的操作各異（例如訂單狀態機）

別用：

狀態少且不會演進（2–3 個 boolean flag），直接 if 更清晰
狀態轉換純粹線性，沒有分支邏輯
用 Spring Statemachine 等成熟框架更合適的複雜場景（別重造輪子）

4. Java 範例

訂單狀態機（PENDING → PAID → SHIPPED → DELIVERED）：

Command — 命令模式

Tue, 07 Aug 2018 22:37:50 +0800

1. 意圖

將一個請求封裝為獨立物件（Command），使請求可被排隊、記錄、撤銷或重做。

2. UML 類圖

classDiagram
    class Command {
        <>
        +execute()
        +undo()
    }
    class ConcreteCommand {
        -receiver Receiver
        -previousState State
        +execute()
        +undo()
    }
    class Receiver {
        +action()
    }
    class Invoker {
        -history List~Command~
        +executeCommand(Command)
        +undoLast()
    }
    Command <|.. ConcreteCommand
    ConcreteCommand --> Receiver
    Invoker --> Command

3. 何時用 / 何時別用

用：

需要 undo/redo（文字編輯器、繪圖工具）
請求需要排隊、延遲執行或記錄日誌
支援 macro 操作（一次執行多個命令）

別用：

操作簡單且不需要撤銷，引入 Command 只增加類別數量
Receiver 與呼叫者本就在同一層，直接呼叫更清楚

4. Java 範例

// Command 介面
public interface Command {
    void execute();
    void undo();
}

// Receiver
public class TextBuffer {
    private final StringBuilder buf = new StringBuilder();

    public void insert(int pos, String text) { buf.insert(pos, text); }
    public void delete(int pos, int len)    { buf.delete(pos, pos + len); }
    public String content()                 { return buf.toString(); }
}

// ConcreteCommand
public class InsertCommand implements Command {
    private final TextBuffer buf;
    private final int pos;
    private final String text;

    public InsertCommand(TextBuffer buf, int pos, String text) {
        this.buf = buf; this.pos = pos; this.text = text;
    }

    @Override public void execute() { buf.insert(pos, text); }
    @Override public void undo()    { buf.delete(pos, text.length()); }
}

// Invoker（含歷史紀錄）
public class Editor {
    private final Deque<Command> history = new ArrayDeque<>();

    public void execute(Command cmd) {
        cmd.execute();
        history.push(cmd);
    }

    public void undo() {
        if (!history.isEmpty()) history.pop().undo();
    }
}

// 使用
TextBuffer buffer = new TextBuffer();
Editor editor = new Editor();

editor.execute(new InsertCommand(buffer, 0, "Hello"));
editor.execute(new InsertCommand(buffer, 5, " World"));
System.out.println(buffer.content()); // Hello World

editor.undo();
System.out.println(buffer.content()); // Hello

5. JDK / Spring 真實案例

Runnable / Callable：最精簡的 Command 介面。Runnable 是無回傳值的 execute()；Callable<V> 增加了回傳值，兩者都可丟入 ExecutorService 排隊執行。

Strategy — 策略模式

Tue, 07 Aug 2018 22:37:39 +0800

1. 意圖

定義一族演算法，各自封裝，讓它們可以互相替換。演算法的變化不影響使用它的客戶端。

2. UML 類圖

classDiagram
    class Strategy {
        <>
        +execute(data) Result
    }
    class ConcreteStrategyA {
        +execute(data) Result
    }
    class ConcreteStrategyB {
        +execute(data) Result
    }
    class Context {
        -strategy Strategy
        +setStrategy(Strategy)
        +executeStrategy(data) Result
    }
    Strategy <|.. ConcreteStrategyA
    Strategy <|.. ConcreteStrategyB
    Context --> Strategy

3. 何時用 / 何時別用

用：

同一行為有多種實作，且在執行期需動態切換（排序、壓縮、付款方式）
大量 if/else 或 switch 判斷演算法類型，想用多型取代
演算法需要獨立測試

別用：

只有 2-3 種固定演算法且幾乎不會擴充，enum + switch 更簡單
演算法間差異很小，直接 method overloading 即可
客戶端需要了解不同策略的差異才能選擇，說明抽象程度不夠

4. Java 範例

// Strategy 介面（單一方法，可用 @FunctionalInterface）
@FunctionalInterface
public interface SortStrategy<T> {
    List<T> sort(List<T> data, Comparator<T> comparator);
}

// 兩種具體策略
public class QuickSort<T> implements SortStrategy<T> {
    @Override
    public List<T> sort(List<T> data, Comparator<T> comparator) {
        List<T> result = new ArrayList<>(data);
        result.sort(comparator);   // 借用 JDK TimSort 示意
        System.out.println("QuickSort used");
        return result;
    }
}

public class MergeSort<T> implements SortStrategy<T> {
    @Override
    public List<T> sort(List<T> data, Comparator<T> comparator) {
        // 真實場景放入 merge sort 實作
        List<T> result = new ArrayList<>(data);
        result.sort(comparator);
        System.out.println("MergeSort used");
        return result;
    }
}

// Context
public class Sorter<T> {
    private SortStrategy<T> strategy;

    public Sorter(SortStrategy<T> strategy) { this.strategy = strategy; }
    public void setStrategy(SortStrategy<T> strategy) { this.strategy = strategy; }

    public List<T> sort(List<T> data, Comparator<T> cmp) {
        return strategy.sort(data, cmp);
    }
}

// 使用
Sorter<Integer> sorter = new Sorter<>(new QuickSort<>());
sorter.sort(List.of(3, 1, 4, 1, 5), Comparator.naturalOrder());

// 執行期切換
sorter.setStrategy(new MergeSort<>());
sorter.sort(List.of(3, 1, 4, 1, 5), Comparator.reverseOrder());

// 用 lambda 直接注入（不需要具體類別）
sorter.setStrategy((data, cmp) -> data.stream().sorted(cmp).toList());

5. JDK / Spring 真實案例

Comparator：Collections.sort() 與 List.sort() 的第二個參數就是 Strategy。Comparator.comparing() 讓 lambda 成為最常用的 Strategy 形式。

Observer — 一對多狀態變更通知

Tue, 07 Aug 2018 22:37:21 +0800

1. 意圖

定義物件間一對多的依賴關係，當 Subject 狀態改變時，所有依賴它的 Observer 都會自動收到通知並更新。

2. UML 類圖

classDiagram
    class Subject {
        <>
        +subscribe(Observer)
        +unsubscribe(Observer)
        +notifyObservers()
    }
    class Observer {
        <>
        +update(event)
    }
    class ConcreteSubject {
        -observers List~Observer~
        -state
        +setState(state)
    }
    class ConcreteObserver {
        +update(event)
    }
    Subject <|.. ConcreteSubject
    Observer <|.. ConcreteObserver
    ConcreteSubject --> Observer : notifies

3. 何時用 / 何時別用

用：

一個物件狀態改變，多個物件需要連動更新（MVC model → view）
訂閱關係需要在執行期動態增減
跨模組通知，不希望兩者直接相互引用

別用：

觀察者鏈太長，觸發順序難以追蹤（考慮改用 Mediator）
觀察者之間有依賴順序要求（Observer 本身不保證順序，需額外機制）
簡單的一對一回呼，直接傳 lambda 更清楚

4. Java 範例

Push 模型（Subject 主動推送事件物件）：

Chain of Responsibility — 責任鏈模式

Tue, 07 Aug 2018 22:37:08 +0800

1. 意圖

將請求沿著處理者鏈依序傳遞，每個處理者決定自己是否處理，或繼續往下傳。

2. UML 類圖

classDiagram
    class Handler {
        <>
        #next Handler
        +setNext(Handler)
        +handle(request)*
    }
    class ConcreteHandlerA {
        +handle(request)
    }
    class ConcreteHandlerB {
        +handle(request)
    }
    Handler <|-- ConcreteHandlerA
    Handler <|-- ConcreteHandlerB
    Handler --> Handler : next

3. 何時用 / 何時別用

用：

超過一個物件可能處理同一請求，且處理者在執行期才決定（審批流、過濾管道）
需要動態組裝或重排處理者順序
不想讓發送者知道具體由誰處理

別用：

每個請求必須保證被處理——責任鏈可能讓請求靜默消失
處理者固定且少（2-3 個），直接 if/else 更清楚
鏈很長時效能敏感的熱路徑

4. Java 範例

// 審批請求：金額超過閾值就往上傳
public abstract class Approver {
    private Approver next;

    public Approver setNext(Approver next) {
        this.next = next;
        return next;
    }

    public final void approve(long amount) {
        if (canApprove(amount)) {
            doApprove(amount);
        } else if (next != null) {
            next.approve(amount);
        } else {
            throw new IllegalStateException("No approver for amount: " + amount);
        }
    }

    protected abstract boolean canApprove(long amount);
    protected abstract void doApprove(long amount);
}

public class TeamLead extends Approver {
    @Override protected boolean canApprove(long amount) { return amount <= 1_000; }
    @Override protected void doApprove(long amount) {
        System.out.println("TeamLead approved: " + amount);
    }
}

public class Manager extends Approver {
    @Override protected boolean canApprove(long amount) { return amount <= 10_000; }
    @Override protected void doApprove(long amount) {
        System.out.println("Manager approved: " + amount);
    }
}

public class Director extends Approver {
    @Override protected boolean canApprove(long amount) { return true; }
    @Override protected void doApprove(long amount) {
        System.out.println("Director approved: " + amount);
    }
}

// 組裝鏈
Approver chain = new TeamLead();
chain.setNext(new Manager()).setNext(new Director());

chain.approve(500);     // TeamLead approved: 500
chain.approve(5_000);   // Manager approved: 5000
chain.approve(50_000);  // Director approved: 50000

5. JDK / Spring 真實案例

ClassLoader 親委派：ClassLoader.loadClass() 先委派給 parent，parent 找不到才自己載入，這就是責任鏈的「先傳再自處理」變體。

Mediator — 以中介者解耦多方互動

Tue, 07 Aug 2018 22:36:43 +0800

1. 意圖

引入中介者物件封裝一組物件間的互動，使它們不需直接相互引用，從而將網狀耦合（mesh）降為星狀（star）。

2. UML 類圖

classDiagram
    class Mediator {
        <>
        +notify(sender, event)
    }
    class ConcreteMediator {
        -componentA ComponentA
        -componentB ComponentB
        +notify(sender, event)
    }
    class Component {
        <>
        #mediator Mediator
    }
    class ComponentA {
        +doA()
    }
    class ComponentB {
        +doB()
    }
    Mediator <|.. ConcreteMediator
    Component <|-- ComponentA
    Component <|-- ComponentB
    Component --> Mediator
    ConcreteMediator --> ComponentA
    ConcreteMediator --> ComponentB

3. 何時用 / 何時別用

用：

多個物件互相依賴，耦合關係複雜（N×(N-1)/2 條連線）
需要集中管理通訊流程（例如聊天室、航管、表單欄位聯動）
想讓組件可獨立重用，不綁定特定協作對象

別用：

只有 2–3 個物件互動，直接引用更清晰
中介者本身邏輯膨脹成「God Object」時，應拆分或改用事件匯流排
需要點對點高效能通訊，中間層增加 latency 不划算

4. Java 範例

// 事件類型
public sealed interface ChatEvent permits MessageSent, UserJoined {}
public record MessageSent(String from, String text) implements ChatEvent {}
public record UserJoined(String username) implements ChatEvent {}

// Mediator 介面
public interface ChatMediator {
    void register(ChatUser user);
    void relay(ChatEvent event, ChatUser sender);
}

// ConcreteMediator
public class ChatRoom implements ChatMediator {
    private final List<ChatUser> users = new ArrayList<>();

    @Override
    public void register(ChatUser user) {
        users.add(user);
    }

    @Override
    public void relay(ChatEvent event, ChatUser sender) {
        users.stream()
             .filter(u -> u != sender)
             .forEach(u -> u.receive(event));
    }
}

// Component
public class ChatUser {
    private final String name;
    private final ChatMediator mediator;

    public ChatUser(String name, ChatMediator mediator) {
        this.name = name;
        this.mediator = mediator;
        mediator.register(this);
    }

    public void send(String text) {
        mediator.relay(new MessageSent(name, text), this);
    }

    public void receive(ChatEvent event) {
        switch (event) {
            case MessageSent m -> System.out.printf("[%s] %s: %s%n", name, m.from(), m.text());
            case UserJoined j  -> System.out.printf("[%s] %s joined%n", name, j.username());
        }
    }
}

5. JDK / Spring 真實案例

框架	類別 / 機制	說明
Spring	`ApplicationEventPublisher` + `@EventListener`	發布者只呼叫 `publishEvent()`，監聽者以 `@EventListener` 宣告，互相不知道對方
Spring	`ApplicationContext`	Context 本身就是 Mediator，協調所有 Bean 的生命週期
Java Swing	`ActionListener` / `MediatorPanel`	表單元件透過共同 Controller 通訊，而非彼此直接呼叫

Spring 範例：

Template Method — 模板方法模式

Tue, 07 Aug 2018 12:18:20 +0800

1. 意圖

在抽象父類中定義演算法的骨架（final 方法），將某些步驟延遲到子類實作，讓子類在不改變整體結構的前提下覆寫特定步驟。

2. UML 類圖

classDiagram
    class AbstractClass {
        <>
        +templateMethod()
        #step1()*
        #step2()*
        #hook()
    }
    class ConcreteClassA {
        #step1()
        #step2()
    }
    class ConcreteClassB {
        #step1()
        #step2()
        #hook()
    }
    AbstractClass <|-- ConcreteClassA
    AbstractClass <|-- ConcreteClassB

3. 何時用 / 何時別用

用：

多個類別共用相同的演算法骨架，只有部分步驟不同
想控制子類能擴展的範圍（用 final 保護骨架，protected abstract 開放步驟）
框架設計：讓使用者繼承後填入業務邏輯（Hollywood Principle）

別用：

步驟差異大，繼承層次超過 2 層——改用 Strategy（組合優於繼承）
子類只需客製 1 個步驟，傳入 callback / lambda 比繼承更輕量
需要在執行期切換演算法變體，Template Method 是靜態綁定

4. Java 範例

// 資料匯出的通用骨架
public abstract class DataExporter {

    // 模板方法：final 保護流程
    public final void export(String destination) {
        List<String> data = fetchData();
        List<String> processed = transform(data);
        write(processed, destination);
        if (needsNotification()) {
            notify(destination);
        }
    }

    protected abstract List<String> fetchData();
    protected abstract List<String> transform(List<String> data);
    protected abstract void write(List<String> data, String destination);

    // hook：子類可選擇覆寫
    protected boolean needsNotification() { return false; }
    protected void notify(String destination) {
        System.out.println("Exported to: " + destination);
    }
}

// 具體實作 A：CSV 匯出
public class CsvExporter extends DataExporter {
    private final List<String> source;

    public CsvExporter(List<String> source) { this.source = source; }

    @Override
    protected List<String> fetchData() { return List.copyOf(source); }

    @Override
    protected List<String> transform(List<String> data) {
        return data.stream().map(s -> "\"" + s + "\"").toList();
    }

    @Override
    protected void write(List<String> data, String destination) {
        System.out.println("Writing CSV to " + destination + ": " + data);
    }

    @Override
    protected boolean needsNotification() { return true; } // 覆寫 hook
}

// 使用
DataExporter exporter = new CsvExporter(List.of("Alice", "Bob"));
exporter.export("/tmp/output.csv");
// Writing CSV to /tmp/output.csv: ["Alice", "Bob"]
// Exported to: /tmp/output.csv

5. JDK / Spring 真實案例

AbstractList：indexOf()、lastIndexOf()、iterator() 等方法的骨架實作在 AbstractList，只有 get(int index) 和 size() 是 abstract，ArrayList 與 LinkedList 各自提供這兩個方法。

Decorator — 動態疊加行為

Tue, 07 Aug 2018 12:16:24 +0800

1. 意圖

在不修改原始類別的情況下，透過包裝（組合）動態地為物件附加新功能，作為繼承的彈性替代方案。

2. UML 類圖

classDiagram
    class Component {
        <>
        +operation() String
    }
    class ConcreteComponent {
        +operation() String
    }
    class Decorator {
        <>
        #component Component
        +operation() String
    }
    class ConcreteDecorator {
        +operation() String
    }
    Component <|.. ConcreteComponent
    Component <|.. Decorator
    Decorator <|-- ConcreteDecorator
    Decorator --> Component

3. 何時用 / 何時別用

用：

需要疊加多個獨立的行為，且組合數量多（繼承會類別爆炸）
需要在執行期動態增減功能（不同使用者看到不同裝飾組合）
橫切關注點（logging、retry、rate limit）不想侵入核心邏輯

別用：

只需一種固定擴充，直接繼承或 Strategy 更簡單
裝飾器層數超過 3-4 層，Debug 困難，改用 Pipeline / Chain of Responsibility
需要明確知道具體型別時（Decorator 會遮蔽真實型別）

4. Java 範例

以 HTTP client 為例，疊加 logging 與 retry 裝飾器：

Bridge — 抽象與實作分離

Tue, 07 Aug 2018 12:16:14 +0800

1. 意圖

將抽象部分（Abstraction）與其實作部分（Implementation）解耦，使兩者可以獨立變化，以組合取代繼承。

2. UML 類圖

classDiagram
    class Abstraction {
        #impl Implementor
        +operation()
    }
    class RefinedAbstraction {
        +operation()
    }
    class Implementor {
        <>
        +operationImpl()
    }
    class ConcreteImplementorA {
        +operationImpl()
    }
    class ConcreteImplementorB {
        +operationImpl()
    }
    Abstraction <|-- RefinedAbstraction
    Abstraction --> Implementor
    Implementor <|.. ConcreteImplementorA
    Implementor <|.. ConcreteImplementorB

3. 何時用 / 何時別用

用：

類別沿兩個獨立維度擴展（例如「訊息類型」×「發送通道」），繼承會爆炸
需要在執行期切換實作（如依設定選擇 DB driver）
抽象與實作的演進頻率不同，應各自獨立版本化

別用：

只有一個變化維度，直接繼承或 Strategy 即可
類別數量少且不預期擴展，過度設計
實作層只有一種且未來不會增加

4. Java 範例

以「通知訊息」×「發送通道」為例，兩個維度各自擴展：

// Implementor
public interface MessageSender {
    void send(String recipient, String content);
}

// ConcreteImplementor A
public class EmailSender implements MessageSender {
    @Override
    public void send(String recipient, String content) {
        System.out.println("Email to " + recipient + ": " + content);
    }
}

// ConcreteImplementor B
public class SmsSender implements MessageSender {
    @Override
    public void send(String recipient, String content) {
        System.out.println("SMS to " + recipient + ": " + content);
    }
}

// Abstraction
public abstract class Notification {
    protected final MessageSender sender;

    protected Notification(MessageSender sender) {
        this.sender = sender;
    }

    public abstract void notify(String recipient);
}

// RefinedAbstraction A
public class AlertNotification extends Notification {
    private final String alertMessage;

    public AlertNotification(MessageSender sender, String alertMessage) {
        super(sender);
        this.alertMessage = alertMessage;
    }

    @Override
    public void notify(String recipient) {
        sender.send(recipient, "[ALERT] " + alertMessage);
    }
}

// RefinedAbstraction B
public class PromotionNotification extends Notification {
    private final String promoCode;

    public PromotionNotification(MessageSender sender, String promoCode) {
        super(sender);
        this.promoCode = promoCode;
    }

    @Override
    public void notify(String recipient) {
        sender.send(recipient, "Use promo code: " + promoCode);
    }
}

// 使用：任意組合抽象與實作
Notification n1 = new AlertNotification(new EmailSender(), "Server down");
Notification n2 = new PromotionNotification(new SmsSender(), "SAVE20");
n1.notify("ops@example.com");
n2.notify("+886912345678");

5. JDK / Spring 真實案例

JDBC：Connection（Abstraction）+ 各家 JDBC Driver（ConcreteImplementor）。應用程式的 SQL 邏輯不改，僅替換 driver jar 就能切換 DB 品牌，是最廣為人知的 Bridge 範例。

Facade — 子系統統一入口

Tue, 07 Aug 2018 12:16:02 +0800

1. 意圖

為子系統中一組複雜的介面提供統一、簡化的高階介面，讓客戶端不需了解子系統內部結構即可使用。

2. UML 類圖

classDiagram
    class Facade {
        -subsystemA SubsystemA
        -subsystemB SubsystemB
        +operation()
    }
    class SubsystemA {
        +operationA()
    }
    class SubsystemB {
        +operationB()
    }
    class Client
    Client --> Facade
    Facade --> SubsystemA
    Facade --> SubsystemB

3. 何時用 / 何時別用

用：

子系統複雜（多個類別、多個步驟），客戶端只需使用常見操作
分層架構中降低層與層之間的耦合（如 Service 層封裝 Repository + Cache + Event）
替換或重構子系統時，只需更新 Facade，對外介面不變

別用：

子系統本身已很簡單，Facade 只是增加無意義的轉發層
需要存取子系統完整功能的進階用戶 — Facade 不應強制封鎖，高階用戶可直接使用子系統
把 Facade 設計成 God Class，聚集過多業務邏輯（Facade 不是業務層）

4. Java 範例

電商下訂單流程：封裝庫存、支付、通知三個子系統：

// 子系統 A
public class InventoryService {
    public boolean reserve(String productId, int qty) {
        System.out.println("Reserving " + qty + " x " + productId);
        return true;
    }
}

// 子系統 B
public class PaymentService {
    public boolean charge(String userId, BigDecimal amount) {
        System.out.println("Charging " + userId + " for $" + amount);
        return true;
    }
}

// 子系統 C
public class NotificationService {
    public void sendOrderConfirmation(String userId, String orderId) {
        System.out.println("Email sent to " + userId + " for order " + orderId);
    }
}

// Facade
public class OrderFacade {
    private final InventoryService inventory;
    private final PaymentService payment;
    private final NotificationService notification;

    public OrderFacade(InventoryService inventory,
                       PaymentService payment,
                       NotificationService notification) {
        this.inventory = inventory;
        this.payment = payment;
        this.notification = notification;
    }

    public String placeOrder(String userId, String productId,
                             int qty, BigDecimal price) {
        if (!inventory.reserve(productId, qty)) {
            throw new IllegalStateException("Out of stock: " + productId);
        }
        if (!payment.charge(userId, price.multiply(BigDecimal.valueOf(qty)))) {
            throw new IllegalStateException("Payment failed for user: " + userId);
        }
        String orderId = UUID.randomUUID().toString();
        notification.sendOrderConfirmation(userId, orderId);
        return orderId;
    }
}

// 客戶端只需呼叫一個方法
OrderFacade facade = new OrderFacade(
    new InventoryService(), new PaymentService(), new NotificationService());
String orderId = facade.placeOrder("user-1", "prod-42", 2, new BigDecimal("29.99"));

5. JDK / Spring 真實案例

SLF4J：LoggerFactory.getLogger() 是 Facade，隱藏了 Logback、Log4j、JUL 等底層框架的初始化細節。

Flyweight — 共享內部狀態節省記憶體

Tue, 07 Aug 2018 12:15:57 +0800

1. 意圖

藉由共享內部狀態（intrinsic state），支援大量細粒度物件，避免每個物件都儲存完整狀態造成的記憶體浪費。

2. UML 類圖

classDiagram
    class FlyweightFactory {
        -pool Map~String, Flyweight~
        +getFlyweight(key) Flyweight
    }
    class Flyweight {
        <>
        +operation(extrinsicState)
    }
    class ConcreteFlyweight {
        -intrinsicState String
        +operation(extrinsicState)
    }
    FlyweightFactory --> Flyweight
    Flyweight <|.. ConcreteFlyweight

3. 何時用 / 何時別用

用：

系統中存在大量（數千以上）結構相似的物件
物件的大部分狀態可以外部化（由呼叫端傳入）
記憶體是主要瓶頸

別用：

物件數量少（< 幾百個），共享池的管理開銷得不償失
物件的狀態幾乎全是外部狀態，共享不了多少
需要物件獨立身份（identity）時，共享會破壞語意

4. Java 範例

以文字編輯器的字元樣式（字型、大小）為例：

// 內部狀態（共享，不可變）
public record TextStyle(String fontFamily, int fontSize, boolean bold) {}

// Flyweight：只儲存內部狀態
public class CharFlyweight {
    private final TextStyle style; // intrinsic

    public CharFlyweight(TextStyle style) {
        this.style = style;
    }

    // extrinsicState：位置、顏色等由外部傳入
    public void render(char c, int x, int y, String color) {
        System.out.printf("'%c' at (%d,%d) color=%s font=%s %dpx bold=%b%n",
            c, x, y, color, style.fontFamily(), style.fontSize(), style.bold());
    }
}

// Factory：管理共享池
public class CharFlyweightFactory {
    private static final Map<TextStyle, CharFlyweight> POOL = new ConcurrentHashMap<>();

    public static CharFlyweight get(TextStyle style) {
        return POOL.computeIfAbsent(style, CharFlyweight::new);
    }

    public static int poolSize() { return POOL.size(); }
}

// 使用：1000 個字元，但共享池只有 2 個 Flyweight 物件
TextStyle normal = new TextStyle("Arial", 12, false);
TextStyle bold   = new TextStyle("Arial", 14, true);

for (int i = 0; i < 500; i++) {
    CharFlyweight f = CharFlyweightFactory.get(normal);
    f.render('A', i, 0, "black");
}
for (int i = 0; i < 500; i++) {
    CharFlyweight f = CharFlyweightFactory.get(bold);
    f.render('B', i, 20, "red");
}
System.out.println("Pool size: " + CharFlyweightFactory.poolSize()); // 2

5. JDK / Spring 真實案例

Integer.valueOf(int)：JDK 快取 -128 到 127 的 Integer 實例（IntegerCache）。Integer.valueOf(100) == Integer.valueOf(100) 為 true，因為回傳同一個物件。

Proxy — 控制物件存取的代理層

Tue, 07 Aug 2018 12:15:41 +0800

1. 意圖

為另一個物件提供替代品（surrogate），在不改變用戶端介面的前提下，攔截並控制對原始物件的存取。

2. UML 類圖

靜態 Proxy

classDiagram
    class Subject {
        <>
        +request()
    }
    class RealSubject {
        +request()
    }
    class Proxy {
        -realSubject RealSubject
        +request()
    }
    Subject <|.. RealSubject
    Subject <|.. Proxy
    Proxy --> RealSubject

JDK Dynamic Proxy

classDiagram
    class InvocationHandler {
        <>
        +invoke(proxy, method, args) Object
    }
    class LoggingHandler {
        -target Object
        +invoke(proxy, method, args) Object
    }
    class Proxy {
        +newProxyInstance(loader, interfaces, handler)$
    }
    InvocationHandler <|.. LoggingHandler
    LoggingHandler --> Proxy : creates

3. 何時用 / 何時別用

用：

Composite — 樹狀結構統一操作

Tue, 07 Aug 2018 12:15:31 +0800

1. 意圖

將物件組合成樹狀結構以表示「部分—整體」層次，讓客戶端對單個物件（Leaf）與組合物件（Composite）使用相同的介面。

2. UML 類圖

classDiagram
    class Component {
        <>
        +operation()
        +add(Component)
        +remove(Component)
    }
    class Leaf {
        +operation()
    }
    class Composite {
        -children List~Component~
        +operation()
        +add(Component)
        +remove(Component)
    }
    Component <|.. Leaf
    Component <|.. Composite
    Composite --> Component : children

3. 何時用 / 何時別用

用：

資料天然形成樹狀結構（檔案系統、組織圖、選單、UI 元件樹）
希望客戶端程式碼不需判斷「這是葉子還是組合」就能統一呼叫

別用：

結構扁平，沒有遞迴嵌套需求
需要對 Leaf 與 Composite 做不同型別處理（型別安全比透明性更重要時，用 Safe 設計或 Visitor）

4. Java 範例

Transparent 設計（Leaf 實作 add/remove 丟例外）vs Safe 設計（Leaf 不宣告 add/remove）。以下示範較常見的 Transparent 設計，並以組織圖為例：

Adapter — 介面轉換橋接

Tue, 07 Aug 2018 12:12:36 +0800

1. 意圖

將一個類的介面轉換為客戶端所期望的另一個介面，讓原本因介面不相容而無法協作的類能夠一起工作。

2. UML 類圖

classDiagram
    class Target {
        <>
        +request()
    }
    class Adaptee {
        +specificRequest()
    }
    class Adapter {
        -adaptee Adaptee
        +request()
    }
    Target <|.. Adapter
    Adapter --> Adaptee

3. 何時用 / 何時別用

用：

整合第三方 SDK，其介面與系統定義不同
改造遺留系統，在不修改舊程式的前提下接入新介面
統一多個來源的異構實作（如多家支付閘道）

別用：

介面差異極大，轉換邏輯超過 50 行 — 考慮重新設計
新系統，沒有遺留限制 — 直接設計統一介面即可
只為了「看起來統一」而包裝，沒有實際轉換需求

4. Java 範例

Object Adapter（組合，優先選用）：

// 目標介面（系統期望）
public interface PaymentGateway {
    boolean charge(long amountCents, String currency);
}

// 第三方 SDK（不可修改）
public class StripeClient {
    public StripeResponse createCharge(String amount, String currency, Map<String, String> meta) {
        // ... Stripe API call
        return new StripeResponse(true, "ch_123");
    }
}

// Object Adapter
public class StripeAdapter implements PaymentGateway {
    private final StripeClient stripe;

    public StripeAdapter(StripeClient stripe) {
        this.stripe = stripe;
    }

    @Override
    public boolean charge(long amountCents, String currency) {
        String amount = String.valueOf(amountCents);
        Map<String, String> meta = Map.of("source", "adapter");
        StripeResponse resp = stripe.createCharge(amount, currency, meta);
        return resp.isSuccess();
    }
}

Class Adapter（繼承，Java 以 implements 模擬）：

Prototype — 透過複製建立新物件

Tue, 07 Aug 2018 02:27:13 +0800

1. 意圖

透過複製（clone）一個已存在的實例來建立新物件，而非重新執行昂貴的初始化流程；同時讓客戶端程式碼無須知道被複製物件的具體類別。

2. UML 類圖

classDiagram
    class Prototype {
        <>
        +clone() Prototype
    }
    class ConcretePrototype {
        -field String
        +clone() ConcretePrototype
    }
    class Client {
        +operation()
    }
    Prototype <|.. ConcretePrototype
    Client --> Prototype : clones

3. 何時用 / 何時別用

用：

物件初始化成本高（讀檔、查 DB、複雜計算），複製遠快於從頭建立
執行期才知道要建立哪種物件（動態原型 Registry）
需要建立一批狀態相近但略有差異的物件（預設設定 + 各自微調）

別用：

物件欄位多且包含深層嵌套可變物件，深拷貝邏輯難以維護
只是要建立同類型的新物件且初始化不昂貴，直接 new 即可
循環引用結構（兩個物件互相持有參考），深拷貝容易陷入無窮遞迴

4. Java 範例

核心陷阱：淺拷貝共享可變物件

public class OrderTemplate {
    private String product;
    private List<String> tags;  // 可變物件

    public OrderTemplate(String product, List<String> tags) {
        this.product = product;
        this.tags    = tags;
    }

    // 淺拷貝：tags 仍指向同一個 List
    public OrderTemplate shallowCopy() {
        return new OrderTemplate(this.product, this.tags);
    }

    // 深拷貝：透過拷貝建構子，tags 獨立
    public OrderTemplate deepCopy() {
        return new OrderTemplate(this.product, new ArrayList<>(this.tags));
    }

    public List<String> getTags() { return tags; }
    public String getProduct()    { return product; }
}

// 驗證差異
var original = new OrderTemplate("Book", new ArrayList<>(List.of("edu")));
var shallow  = original.shallowCopy();
var deep     = original.deepCopy();

shallow.getTags().add("sale");  // original.tags 也被改動！
deep.getTags().add("promo");    // original.tags 不受影響

使用 Jackson 做任意深拷貝（適合已有 ObjectMapper 的場景）

Builder — 分離複雜物件的建構與表示

Tue, 07 Aug 2018 02:16:32 +0800

1. 意圖

將一個複雜物件的建構步驟與最終表示分離，使同樣的建構流程可以產生不同的物件，同時消除因可選參數過多而衍生的「伸縮建構子」反模式。

2. UML 類圖

classDiagram
    class Director {
        +construct(Builder)
    }
    class Builder {
        <>
        +buildPartA()
        +buildPartB()
        +getResult() Product
    }
    class ConcreteBuilder {
        -product Product
        +buildPartA()
        +buildPartB()
        +getResult() Product
    }
    class Product
    Director --> Builder
    Builder <|.. ConcreteBuilder
    ConcreteBuilder --> Product

3. 何時用 / 何時別用

用：

建構子有 4 個以上參數，且部分為可選（Effective Java Item 2）
物件不可變（immutable），但欄位多到無法一次傳入
需要在 build() 時做跨欄位的驗證邏輯

別用：

欄位少且全為必填，直接用建構子更清晰
物件非常簡單（考慮改用 Java Record）
效能極敏感路徑（每次 build() 都產生一個中間 Builder 物件）

4. Java 範例

以 HTTP 請求設定為例，展示必填欄位在 Builder 建構子中固定、可選欄位採 fluent 設定：

Factory Method — 讓子類決定實例化哪個類別

Tue, 07 Aug 2018 01:07:16 +0800

1. 意圖

定義一個建立物件的介面，但將實際要實例化哪個類別的決定延遲到子類別，讓框架程式碼只依賴抽象，由具體子類別決定產品。

2. UML 類圖

classDiagram
    class Creator {
        <>
        +factoryMethod()* Product
        +someOperation()
    }
    class ConcreteCreator {
        +factoryMethod() Product
    }
    class Product {
        <>
        +use()
    }
    class ConcreteProduct {
        +use()
    }
    Creator <|-- ConcreteCreator
    Product <|.. ConcreteProduct
    Creator ..> Product : creates
    ConcreteCreator ..> ConcreteProduct : creates

3. 何時用 / 何時別用

用：

框架提供擴充點，讓呼叫端決定要建立哪種物件（如 JUnit TestCase 建立 TestResult）
產品類型在編譯期未知，需在執行期由設定或輸入決定
希望透過繼承擴充建立邏輯，而非修改既有程式碼（OCP）

別用：

產品種類固定且少（改用 Static Factory Method 就夠了）
為了「彈性」而過度抽象，衍生只有一個 Creator 子類的無謂繼承
搭配 Spring DI 時，通常直接注入 List<Strategy> 再用 Map 查找即可

4. Java 範例

// Product 介面
public interface Notifier {
    void send(String to, String message);
}

// Concrete Products
public class EmailNotifier implements Notifier {
    @Override
    public void send(String to, String message) {
        // 送出 Email
    }
}

public class SmsNotifier implements Notifier {
    @Override
    public void send(String to, String message) {
        // 送出 SMS
    }
}

// Creator
public abstract class NotificationService {

    // Factory Method
    protected abstract Notifier createNotifier();

    public void notify(String to, String message) {
        Notifier notifier = createNotifier();
        notifier.send(to, message);
    }
}

// Concrete Creators
public class EmailNotificationService extends NotificationService {
    @Override
    protected Notifier createNotifier() {
        return new EmailNotifier();
    }
}

public class SmsNotificationService extends NotificationService {
    @Override
    protected Notifier createNotifier() {
        return new SmsNotifier();
    }
}

5. JDK / Spring 真實案例

案例	說明
`java.util.Calendar.getInstance()`	依 Locale / TimeZone 回傳不同子類（BuddhistCalendar、GregorianCalendar）——這是靜態工廠方法，但體現相同「延遲決定具體類別」概念
`java.sql.Connection.createStatement()`	`Connection` 是 Creator，各 JDBC Driver 子類決定回傳哪種 `Statement`
`javax.xml.parsers.DocumentBuilderFactory.newDocumentBuilder()`	抽象工廠方法，實作由 SPI 決定
Spring `BeanFactory.getBean()`	IoC 容器本身是一個大型 Factory Method，`BeanDefinition` 決定實際建立哪個類別

6. 與相近 Pattern 的差異

常見混淆釐清：

Singleton — 確保唯一實例

Mon, 06 Aug 2018 23:05:44 +0800

1. 意圖

確保一個類別在整個 JVM 中只存在一個實例，並提供全域存取點。

2. UML 類圖

classDiagram
    class Singleton {
        -Singleton instance$
        -Singleton()
        +getInstance()$ Singleton
    }

3. 何時用 / 何時別用

用：

需要全域唯一狀態的資源管理器（Connection Pool、ConfigRegistry）
重量級物件初始化一次即可（載入設定檔、建立 thread pool）

別用：

帶可變共享狀態的業務邏輯 — 難以測試、造成隱式耦合
可以用 DI 容器管理生命週期的場景（Spring 已處理）
需要子類化或實作多態的情境

4. Java 範例

三種主流寫法，依推薦順序排列。

Enum 單例（首選）

public enum AppConfig {
    INSTANCE;

    private final Properties props = new Properties();

    AppConfig() {
        try (var in = getClass().getResourceAsStream("/app.properties")) {
            if (in != null) props.load(in);
        } catch (IOException e) {
            throw new ExceptionInInitializerError(e);
        }
    }

    public String get(String key) {
        return props.getProperty(key);
    }
}

Enum 的 JVM 保證讓它天生防止反射攻擊與序列化漏洞。