iT邦幫忙

2022 iThome 鐵人賽

DAY 13
2
自我挑戰組

【從工程師升級成為資深工程師的那檔事】 系列 第 13

【從工程師升級成為資深工程師的那檔事Day 13】創建型設計模式(總結)

  • 分享至 

  • xImage
  •  

現在網路這麼發達相信大家在很多地方都已經可以只找到各種的設計模式,
所以在這個系列文中會花更多一點的篇幅與大家分享如何在實際開發中運用我們學到的觀念與技巧。

現在很多公司都從傳統的瀑布式開發轉向敏捷式開發,
這時候我們也要隨之更改我們的開發方式
從以往的精準開發變成了快速開發

開發初期

在開發初期我們可以先對於我們要建立的物件(Object)做個簡單的判斷:

  • 當物件(Object)未來可能有擴展性的時候使用簡單工廠(Simple Factory)
  • 當物件(Object)暫時沒想到任何擴展功能就不做任何設計,直接依賴在高層的模組

對於快速開發來說,最初撰寫出來的程式碼,
與最終的結果樣樣貌常常是相差甚遠。
開發的初期大多數時候都可以先用簡單工廠(Simple Factory)來幫我們創建物件,
一方面它的結構簡單,另一方面也幫我們完成了模組間的隔離。
在未來需要應用的時候,方便我們再去做修改。

但是簡單工廠(Simple Factory)在簡單還是比不上new物件(Object),
所以當遇到沒有任何擴展功能需要設計的物件(Object)請大膽的給他new下去。

重構

在開發經過幾次的迭代之後,會慢慢地發現前面的設計開始有一些不敷使用了,
這時我們通常會遇到幾種狀況。

  1. 希望系統物件產生單一實例
  2. 需要判斷或創建時有太多設定(簡單說就是要做一些初始化設定才能建立物件)
  3. 需要產生相同的物件

希望系統物件產生單一實例

這種情況的重構非常簡單,通常這問題都會在開發初期就就發現有重構的需求。
而且也幾乎會是處於沒設計的狀態,這時候只要把它改成單例模式(Singleton Pattern)就能解決問題了

需要判斷或創建時有太多設定

這兩個問題會擺一起說是因為,這兩個問題常常會一同出現。
例如:當擁有不同權限的角色進入系統後需要展現不同的畫面。
這問題同時需要考慮進入系統的角色,另一方面需要考慮如何創建畫面。
這時候生成器模式(Builder Pattern)就能很好的幫我們解決問題。

那如果只有流程上需要判斷而沒有複雜的創建行為呢?
這時候個人是建議就繼續使用簡單工廠模式就好。
雖然我們前面有提到的抽象工廠(Abstract Facory),能幫我們很好的解決問題。
但大多數時候,我們更可能因為這樣的設計花費了更多的時間(並沒有得到更高的效益)

需要產生相同的物件

遇到這類的情形通常會使用複合的設計模式來完成。
可以透過工廠模式 + 原型模式 來解決這問題,
先利用工廠幫我們製造出一些原型物件存在工廠內部,
每當外部需要使用時,透過複製的方式產生一個物件給外部使用。

結語

創建型設計模式到這邊就告一個段落了,
接下來的篇章我們會開始分享 結構型設計模式


上一篇
【從工程師升級成為資深工程師的那檔事Day 12】設計模式 - 原型模式
下一篇
【從工程師升級成為資深工程師的那檔事Day 14】設計模式 - 適配器模式
系列文
【從工程師升級成為資深工程師的那檔事】 30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言