iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 3
0
自我挑戰組

來讀設計模式:Junior developer 跟大家一起練功系列 第 19

DAY19: 討論工廠模式

今天我們會再更近一步討論工廠模式,討論為何工廠物件能夠幫助我們簡化程式碼,以及了解工廠物件的一些原則與背後的意義。

何謂工廠?

首先,我們先來定義「工廠」的含義。工廠是用來實體化其他物件的方法(靜態或非靜態)、物件或其他任何實體。

DAY14 介紹到的就是工廠的一個例子(實體化了一組或一系列物件)。 GoF 在 《DESIGN PATTERN》一書中將模式依照概念性的動機做分類:

分類 意圖 用途
行為型 提供靈活(變化)行為的方式 封裝變化
結構型 將己有的物件組合起來 處理介面將實作與抽象聯繫起來
建立型 管理物件的建立 實體化物件

其中,建立型模式包含以下幾個:

  • Abstract Factory 模式
  • Builder 模式
  • Factory Method 模式
  • Prototype 模式
  • Singleton 模式

使用工廠的背景

本書作者提到:

先考慮系統中需要什麼,然後再去關注如何建立系統⋯⋯也就是說,我們應該在確定了物件是什麼之後再定義工廠。

這項原則在 DAY15 有提到。

如此一來的好處⋯

我們將開發做兩部分處理:

  1. 定義物件和它們的合作方式(使用物件)
  2. 編寫為相應實體化物件並在物件共用時管理已有物件的工廠(建立物件)

內聚性更高

Step1 無須操心哪個物件應該要實體化;Step2 則無須操心物件的合作方式。這讓兩個步驟的內聚性變得更好,因為不依循上述方式,程式碼就必須既處理功能又負責在各種流程中建構物件。

耦合度變鬆

作者建議:物件應該要嘛建構和/或管理其他物件,要嘛使用物件,而不應該兼而有之。

遵守這個約束也會使耦合度降低。因為這能讓客戶(Client)與它們使用的物件是解耦的。

封裝變化

這樣的方式將實作類別對客戶完全隱藏。增加新的實作或刪除已有的實作,都不會影響客戶本身。下面兩張圖為客戶與工廠的視角。

客戶視角

工廠視角

可測試性提升

因為客戶的行為應該與任何衍生類別物件相同。如此也就無須測試所有可能的組合,因為我可以單獨測試各個部分。

遵守開閉原則,使維護更容易

使用模式有助於我們遵守開閉原則 —— 需要修改時,應增加新程式碼,而不是修改舊程式。這樣能夠降低維護成本。工廠模式在這給了我們這樣的好處:

  • 將程式碼的修改盡量限於工廠內,主程式上的工作越少
  • 需要修改時,通常要嘛是修改需要的物件,要嘛是修改某些使用物件的方式。工廠有助於將維護限制在物件的使用者或建構者上,同時修改兩者的機會將大大降低

接下來

接下來,我會繼續介紹下一個設計模式:Singleton 模式和 Double-Checked Locking 模式。先這樣,ㄅㄅ!


上一篇
DAY18: Template Method 模式
下一篇
DAY20: Singleton 模式與 Double-Checked Locking 模式
系列文
來讀設計模式:Junior developer 跟大家一起練功22

尚未有邦友留言

立即登入留言