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

• 2021 年 1 月 7 日
• 筆記
• Head First 設計模式, 設計模式

思考題

如何將實例化具體類的程式碼從應用中抽離，或者封裝起來，使它們不會干擾應用的其他部分？ 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