譯者 | 胥磊
審校 | 孫淑娟
軟件行業中幾乎在每個公司，我們都會聽到一些話題的討論，我相信關于設計模式的爭論絕對是其中之一。你甚至可以找到無數的帖子、文章或者Quora和Stackoverflow上的問題的問答無不是在爭論設計模式，前些天我就看到了Quora上一個很古老的問題：“為什么現在程序員很少談及設計模式？哪些模式（如果有的話）依然還有價值？”顯然提問者所說的設計模式是面向對象的設計模式，更確切的說是GoF書中介紹的那23種設計模式，當然大多數回答問題的人也都是這么認為的。
“設計模式”這個術語已然成了“面向對象的設計模式”的代名詞，所以當你遇到“設計模式已死”的這種奇怪說法時不要感到震驚。在這篇文章中，我們將重新聲明下什么是設計模式，這有助于我們在討論或使用某種設計模式時，能使我們確定我們究竟在談論或使用的是什么。
1、設計模式對你意味著什么？
讓我們拋開所有的書面上的定義和解釋，當提到設計模式這個概念時你首先想到的是什么？一個不該被打破的規則？或是一個字斟句酌的學術建議？亦或是又一個的設計約束？還是說一個你只需要知道就能通過求職面試的法寶？
對我來說，設計模式就像我腦海中的喃喃警語，時刻提醒我不要重復造車輪。你可能有過類似的沖動，當遇到一個問題后就想立即找出應對的解決方案，并開始設計/編寫程序——如果是這樣的話，那么你也是一個重復造車輪的人。設想一下如果已經有一個現成的解決方案，你再去創造一個到頭來只是浪費了不必要的時間和精力。盡管這種沖動可能會隨著時間的推移而有所克制，但要完全克服這種沖動情緒，我相信設計模式就是“良藥”之一。
許多軟件工程師應該都碰到過一個相似的問題，因為某些原因都以某種特定的方式解決了它。上述情況同時也提醒了我，這背后可能隱藏了一個道理，啟示我們要從不同角度去看待問題，即使我們很少這么干。讓我們看一下GoF的書中介紹的一段：
“我們都知道設計經驗的價值，但你又有過多少次那種“似曾相識”的感覺的經歷——那種你曾經解決過類似問題，但卻不知道在哪以及如何解決的感覺？如果你能記住以前問題的細節以及解決的方法，那么你就可以重新使用這種經驗，而不是再次去找解決問題的方案”。
或多或少我們都有過類似的經歷：當我們無法記住之前的解決方案時，就會出現反復去解決同一個常見的設計問題的情況。設計模式就是重用解決方案去解決反復出現的問題，從而節省了我們的時間和精力，可以轉而去做其他事情。現在，讓我們深入探討一些模式的基本概念和定義。
2、模式意味著什么？
什么是模式？模式的概念并不是軟件行業所特有的，其他學科和行業如建筑學、經濟學等同樣適用。讓我們來看下建筑學界權威人士克里斯托弗-亞歷山大對模式的定義：
“每種模式都是一個由三部分組成的規則，它描述了某種背景、問題和解決方案之間的關系。”(Alexander, 1979)“每個模式都描述了一個在我們的環境中反復出現的問題，然后描述了解決這個問題的核心。通過這種方式，你就可以無數次地使用這個解決方案，而不是用同樣的方式做多次。”(Alexander, 1977)
現在讓我們看看模式在軟件行業的意義。“軟件架構的設計模式描述了在特定的設計環境中反復出現的特定的設計問題，并為其提供了一套可行的通用方案。解決方案是通過描述其組成部件、它們之間責任和關系以及協作方式來指定的。”(BMRSS, 96)
基于上述定義，我們可以將模式視為背景、問題和解決方案三者之間的有機結合。它是一個寬泛的概念，可以應用于不同的規模和抽象層次，從設計整個軟件系統到解決特定編程語言的設計問題都可以應用。
3、不同的模式類別
模式是根據其規模和抽象程度來分類的：
（1）架構模式
（2）設計模式
（3）習語
架構模式關注的是整個軟件系統的架構，它的子系統，不同的大組件，以及它們的結合方式。這種模式是一種高層級的抽象，并不關心編程語言是什么，也不關心使用的是什么框架。
“架構模式描述了軟件系統的基本結構的組織模式。它提供了一套預定義的子系統，并規定了它們的責任，其中包括組織它們之間關系的規則和指導手冊”。(BMRSS, 96)
另一方面，我們在最低的抽象層次上也有一些模式，稱之為習語，它涉及到設計和實現。習語是針對特定語言的，也就是說A語言中的習語在B語言中是不相干的。“習語是一種針對特定編程語言的低級模式。習語描述了如何使用給定語言的特性來實現特定方面的組件或組件之間的關系”。(BMRSS, 96)。在上述那些規模和抽象水平的模式之間，還有一些其他的模式，那就是設計模式。
4、設計模式的近距離觀察
讓我們回顧一下設計模式的定義：“設計模式為完善軟件系統的子系統或組件，以及它們之間的關系而提供的一個方案。它描述了一個相互通信的組件的常見結構，用以解決特定的環境中常見的設計問題”。(BMRSS, 96) 。設計模式屬于中等規模，這意味著它們既不像架構模式那樣高度抽象，也不像習語那樣與編程語言耦合。使用設計模式并不影響軟件系統的架構，但它會影響子系統的結構及其較小的組件。
現在讓我們來討論下面這句話（摘自同一參考文獻），其中包含了關于設計模式的一個重要事實。“它們往往獨立于某種特定的編程語言或編程范式”。(BMRSS, 96) 。根據之前在文章中談到的模式類別，我們重新表述一下：“它們獨立于一種特定的編程語言，但往往（不總是）依賴于一種編程范式。”這句話的第一部分很清楚：如果一個模式依賴于特定的編程語言，那么它就屬于習語的范疇。關于第二部分，設計模式是為解決編程范式中出現的常見問題而做出的嘗試。它們很可能是對范式的缺陷的應對。例如GoF書中描述的23種面向對象的設計模式，其中大部分都不是函數式編程范式中的關注點。反過來也一樣，因為設計模式都有不同的背景。正如你在下圖中看到的，不同的范式可以共享設計模式，但我們不打算討論這個話題，因為它超出了本文的范圍。
5、一個著名觀點的分析
記住前面的章節，讓我們快速瀏覽一下當你簡單地用谷歌搜索設計模式時可能遇到的觀點：函數式編程語言不需要設計模式。你可以在這里找到答案，顯然這種說法是錯誤的，因為它暗示設計模式只屬于面向對象范式。設計模式是一個在函數式編程范式和面向對象編程范式中都可以存在的概念，設計模式是針對各種范式的問題和需求而設計的。函數式編程范式同樣有專門針對其背景的設計模式。此外，正如我們在前幾節所討論的，不同的范式有不同的背景，因此就會遇到不同的問題，我們不應該指望范式B的設計模式來解決范式A的問題。
6、快速回顧
設計模式與其他模式類型類似，試圖解決一個特定環境中反復出現的問題。
（1）它們是獨立于語言的，但大多是跟范式耦合。
（2）作為中等規模，它們不像架構模式那樣抽象。
（3）它們的應用并不影響軟件系統的基本架構，但會影響子系統的架構。
（4）最后但也同樣重要的是，它們是（所有類型的模式）防止我們重復造輪的手段。
在我看來設計模式并不是約束我們設計的嚴格規則。它們既不是固定的，也不是無懈可擊的，因為它們可以進化，可以變得完善，甚至可以消逝，但模式的概念仍然存在。遵循模式就像是一種思維方式，幫助我們找出可能更好的解決方案。
原文鏈接：https://dzone.com/articles/a-seemingly-simple-question-what-are-design-patter
譯者介紹
胥磊，51CTO社區編輯，某頭部電商技術副總監，關注Java后端開發，技術管理，架構優化，分布式開發等領域。
