為什麼要使用設計模式？

與他人一起工作

寫程式時要保持這種心態：就好像將來要維護你這些程式的人是一位殘暴的精 神病患者，而且他知道你住在哪。（Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.） - Martin Golding

寫程式並不是一件孤單的事。在開發的過程中，會有其他的同仁共同參與，你可能接手前人的程式，也可能會有人接手你現在撰寫的程式；程式不只是一批只交付給機器執行的命令，也是一種讀物，你閱讀別人的程式，別人也會閱讀你的程式，因為程式就是寫作與閱讀，所以程式本身就是溝通。

你想要讀懂別人的程式，也想要讓別人可以讀懂你的程式，那麼在工程師之間就需要一套共同的詞彙與修辭學。

如果我們把變數想像成單字、把程式語言的語法想成文法，那麼我們知道，有時候一篇文章就算你每個字都看得懂，但是把每個字串在一起，你就是不知道裡頭到底想要表達什麼，所以你就會需要一套把不同元素組合在一起的敘事結構，像是起承轉合、像是倒敘法…在物件導向程式中，這種排列方式就是設計模式。

學習設計模式就是學習工程師的語言，使用設計模式就是與其他工程師溝通，讓其他參與人可以快速理解整個軟體的架構。

適應軟體的變化

如果我們把設計模式理解成物件的排列方式，我們透過一套有系統的方式，把物件組織起來，也就是管理物件之間的關係。而管理物件的關係，除了代表讓一些物件有關係之外，同時也代表讓許多物件之間沒有關係，解除物件之間的相依性。

如果在一個有了一些年紀的 code base 上工作，你會發現，所謂維護一套軟體，其實就是在不斷改動軟體，你不但要讓基本功能隨著時間過去、作業系統與 SDK 的改版還能夠繼續運作，還要隨著每年的商業目標改變而滿足不同的需求，有些新的需求會誕生，有些過去的需求會不復存在，你會不斷增加新的功能，另一方面，你也會需要不斷移除沒有用的程式碼。

從軟體中移除程式碼遠比加入程式碼困難，如果我們加入程式碼的時候就像把一把紅豆灑進一缸綠豆，那麼刪除程式碼就像是要從一缸綠豆裡頭把這一把紅豆一顆一顆挑出來。如果一開始每個物件之間的關係都糾結在一起，當我們想要移除沒有用到的程式時，根本就無從下手，而放任無用的程式繼續在軟體中存活，最終就會危害整體的軟體品質。

維護軟體就是改動軟體，撰寫單元測試是為了有工具可以讓我們在改動的時候，確認沒有把軟體改爛，使用設計模式則是讓我們想要改動的時候還有辦法改得動。維護一套有一些年紀的軟體，在每次把程式加進去的時候，都要考慮以後你要怎麼把這些程式拿出來。