Creational on Bill.Lin's Notes

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 保證讓它天生防止反射攻擊與序列化漏洞。