摸爬滾打學設計模式

此系列文章的寫作初衷，是記錄一些學習設計模式的心得，藉此溫習、總結，盡量用簡要的語句和示例來介紹各種設計模式。在此過程中，鍛煉自己的表達能力，同時也可以與他人分享、交流知識。參考的教材是《設計模式》（清華大學出版社，劉偉主編、胡志剛、郭克華副主編）。

文章目錄（不定期更新）：

【一】工廠模式【二】建造者模式、原型模式、單例模式

【三】適配器模式

【四】橋接模式、組合模式、享元模式

前言

每當有「計算機軟體相關行業的從業人員應該具備哪些基礎知識」這種問題在Timeline上出現的時候，大家經常會提到資料庫、網路、操作系統這三座大山，然後再提一提演算法和數據結構什麼的，然而卻很少看到人提到設計模式。

大學期間所接觸的編程語言主要是C++和Java，雖然跟同學們做過不少項目，也參加過一些演算法比賽（雖然自己的水平很差，只能跟著打打醬油），但是這些事情，感覺我們提到的如何優雅地寫代碼直接關係不是特別大。尤其是演算法比賽跟一些課程作業，根本不需要涉及多少面向對象的內容，乃至寫代碼就跟寫流水賬一樣。

由於這樣的編程習慣，大家寫出來的代碼往往都各有各的風格，換一個人看的時候就開始變得有些難以理解，稍微需要變動時，就感覺牽一髮而動全身。

於是大家經常互相吐槽這個代碼你怎麼這麼寫啊，這個代碼好爛啊，而實際上自己的代碼寫得也挺不忍直視，事到如今我還能想起來前年寫的一個純Java項目，代碼量可能也有個好幾萬行吧，但是一個介面都沒用過…甚至很多同學認為設計模式都是一些人搞出來的玄學，總共也就那麼點，看上去很高大上，跟各種演算法和奇技淫巧比起來，其實也沒什麼難度。其實這就有一些偏見了。

在實習的時候，也聽到很多前輩對於一些舊代碼的吐槽，當時我也跟著吐槽，回頭一看自己代碼不禁嚇出一身冷汗，卧槽。在開始了初步的學習後，我發現，相對需要花大量時間刷題以及鍛煉思維的演算法訓練而言，其實學習設計模式的性價比是非常不錯的，它能迅速幫助編碼者把代碼變得優雅，讓你在寫代碼的時候神清氣爽，就像吃了綠箭一樣，但是它的作用還遠不止於此。

設計模式是什麼？

設計模式（Design Pattern）起源於對軟體模式的探索。模式最早起源於建築業，模式之父Christopher Alexander博士用了很長的時間來做住宅和周邊環境的資料收集工作，發現人們對於舒適住宅和城市環境存在一些共同的認知規律。這些規律不像物理學和數學規律那樣明顯，或者一定有確定的結論，但是通過統計這些規律，可以得到一些場景下對應問題的較優解決方案。

上個世紀末軟體工程界開始關注Alexander博士的研究，當時行業正處於快速發展的階段，就像工業界很多模具與生產流水線的出現一樣，大家也希望找到軟體開發上的一些可以通用化、模板化的東西，來幫助提高開發效率。於是設計模式應運而生。簡單地來說設計模式就是大家在寫代碼的過程中總結出來的一些套路，可以在對面一些問題時，直接用這些套路來解決，而且這些套路經過了大家的實踐檢驗，被公認為是非常棒的套路。

在這些套路發展的過程中，大家發現除了可以反覆使用以外，這些套路能不能經得住產品經理的考驗也很重要，於是就出現了解耦、抽象的概念，方便代碼改來改去也不慌。

總的來說，設計模式是一套被反覆使用的，多數人知曉的，經過分類編目的、代碼設計經驗的總結，使用設計模式是為了可重用代碼（就可以偷懶了），讓代碼更容易被他人理解（不會出現「哇你這個代碼怎麼回事」了），保證代碼可靠性（減少「哇你的代碼怎麼這麼多bug」的出現情況）。

狹義的設計模式是指GoF的《設計模式：可復用面向對象軟體基礎》一書中提到的23種經典設計模式，而實際上隨著技術的發展和需求的變更，設計模式可能越來越多。

學習設計模式的好處

提高解決問題的效率

設計模式的四個要素：模式名稱、問題、解決方案、效果。其實這就是說在XX情況下我們可以用XX套路，當對設計模式熟悉以後，我們也會對遇到的問題進行快速歸類和總結，就像map一樣，許多問題只用常數時間就可以找到問題的解決方法。設計模式就是造好的輪子，既然大家都知道輪子造好就只需要用了，那我們就不需要造一個方的輪子了，滾不利索還有可能翻車…

更容易看懂開源項目

很多開源工程代碼質量都非常高，傳說中質量非常高的代碼都是不需要注釋就能看懂的誒，然後前段時間我看了一下某個項目的代碼…

我覺得這應該是騙我的吧。為什麼我看了半天還是看不懂，後來才知道那個地方用了設計模式中的職責鏈模式，結合職責鏈模式的相關定義我終於把他要幹啥看懂了。這就不得不提到設計模式這個知識點的基礎性，在優秀的工程中，為了代碼的可維護性，必然會使用大量的設計模式，如果不懂設計模式，就算有代碼直接可以參考，也看不懂是啥意思。換句話說，如果想看開源項目學習，在這之前不妨先看看設計模式。

與他人交流問題時更容易描述

設計模式就像LOL里的四一分推，CS里的卡槍一樣，已經是一些很通用化的技巧，當你需要跟其他代碼玩家描述你的問題時，與其業務邏輯巴拉巴拉講了一大堆，常常不如一句「這個大概就是一個XX模式的問題」。在大家已經有既定的問題定義，以及解決方案歸類的前提下，可以更加方便彼此交流，你容易描述了，我也容易聽（看）懂了~

代碼更優雅

如果你是一個強迫症玩家，每天花了一個小時寫代碼，然後七個小時重構代碼讓它變得優雅。

設計模式：看我的操作

強迫症玩家：哇還有這種操作！

早學早賺！

推薦閱讀：