Head First 設計模式 —— 04. 工廠 (Factory) 模式

思考題

如何将執行個體化具體類的代碼從應用中抽離，或者封裝起來，使它們不會幹擾應用的其他部分？

P111

• 将執行個體化具體類的代碼放入一個對象中管理，通過不同入參決定執行個體化具體的類

簡單工廠

不是23種GOF設計模式之一，而更像一種程式設計習慣。

P117

特點

• 通常利用靜态方法建立執行個體，但這樣無法通過繼承來改變建立方法的行為。

  P115

  缺點

• 違反開閉原則，增加産品時需要修改工廠類。

工廠方法模式

定義了一個建立對象的接口，但由子類決定要執行個體化的類是哪一個。

P134

• 工廠方法讓類把執行個體化推遲到子類。

  P134

• “決定”指選用哪個子類，就決定了實際建立哪個子類。

  P134

• 增加産品或改變産品的實作，不會影響工廠接口。

  P135

• 新增産品時，需要增加新的工廠，增加代碼複雜性。

抽象工廠模式

提供一個接口，用于建立相關或依賴對象的家族，而不需要明确指定具體類。

P156

• 抽象工廠的方法經常以工廠方法的方式實作。

  P158

• 把一群相關的産品集合起來。

  P159

• 新增新的相關産品時，需要修改接口和實作類。

  P159

設計原則

• 依賴倒置原則：要依賴抽象，不依賴具體類。

  P139

  • 不能讓高層元件依賴低層元件，并且不管高層元件或低層元件，都應該依賴于抽象。

    P139

  • 低層元件依賴于高層抽象。

    P141

  • 避免違反依賴倒置原則的指導方針（可根據實際情況盡量遵循）

    P143

    • 變量不可以持有具體類的引用
      • 即沒有

        import

        具體類，可以使用工廠避免具體類的引用
    • 不要讓類派生自具體類
      • 【書上解釋】使用時可能會依賴具體類，可是讓類派生自接口或抽象類
      • 【自己想法】隻要具體類派生自接口或抽象類，就可以讓類派生自該具體類
    • 不要覆寫基類中已實作的方法
      • 【書上解釋】基類中已實作的方法，應該由所有的子類共享
      • 【自己想法】書上前面也提到基類可以提供預設的方法，子類可以覆寫為自己的實作

        P135

所思所想

• 其實平時寫代碼時很多時候都倒置了自己的思考方式，比如：依賴某個接口的不同實作完成不同的小功能時，不會先去寫具體的實作，而是根據接口先完成上層的代碼架構，再具體完成每一個實作類。
• 雖然書中說了工廠方法和抽象工廠的差別，但還是感覺兩個差別不大，隻是在應用場景有點差別。工廠方法指建立一類産品，而抽象工廠關鍵相關的多類産品。當相關的産品隻有一類時，抽象工廠就是工廠方法。

  本文首發于公衆号：滿賦諸機（ 點選檢視原文 ） 開源在 GitHub ： reading-notes/head-first-design-patterns