好奇設計模式的源頭，做了一番搜索和調查，于是便開啟了這個系列“PrintJ的設計模式之旅”。

1.模式之父

GOF（Gang of Four）

Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides合著了"Design Patterns: Elements of Reusable Object-Oriented Software"（中文版《設計模式?: 可復用面向對象軟件的基礎》）

。這四位大神是公認的設計模式之父。

但是，大神們又是受到了誰的啟發，基于什么動機去開始這項“偉業”呢？是他們發明了設計模式還是發現了設計模式呢？

帶著這兩個問題，找到了下面這位大神。

Christopher Alexander

C.亞歷山大——加州大學伯克利分校建筑學教授，環境結構中心負責人，寫了"The Timeless Way of Building?: Way of Building"一書（中文版《建筑的永恒之道》）。正式這本書激發了軟件行業對模式的思索。

亞歷山大的問題

亞歷山大要解決建筑設計問題。假設你要建一所大學，必須向學生和老師解釋你的設計，

• 否則建筑工人無法將你的設計變成精妙的建筑。
• 沒有設計師能夠讓工人知道所有他們應該了解的知識。

由于無法將設計向所有的參與者一一解釋清楚，于是你會看到一個巨大的瓦礫堆。

“如何將設計的職責在一個大型組織中進行合理分配，與此同時保證整體設計的一致性與協調性？”

這個問題同樣適用于軟件開發。

亞歷山大的答案

亞歷山大提出了“模式語言”——涵蓋設計決策的一組辭典。

"A Pattern Language : Towns, Buildings, Construction"（中文版《建筑模式語言（上下）?: 城鎮·建筑·構造》）

書中提到了超過250個示例，通過模式語言可以進行設計交流。所有的討論都基于同樣的基礎，提升了設計通用性。

模式是什么？不是什么？

• 模式不會告訴你如何設計
• 模式會幫助你決定需要設計哪些內容
• 你可以自己發明（make up）模式，只要它能夠讓設計變得更好

對GOF設計模式的爭論

GOF的23種設計模式在當時無疑是一種巨大的進步，但同時也有一些局限，比如編程語言。于是產生了一些對設計模式的爭論：

• 一些設計模式在其他編程語言中已經提供了默認實現；
• 你會在代碼里看到GOF的書中示例被到處拷貝；
• GOF設計模式無法靈活地運用……

這里不做口水式的爭論，有興趣的看官可以參考附錄中的文章。

Jeff Atwood的建議

個人覺得Jeff Atwood的建議還是挺中肯的：

學習設計模式沒有問題，但務必更加深入地讀懂建筑模式語言。畢竟，思考比代碼更重要。

題外話

看了這么多設計模式“負面”的內容一定會有所懷疑吧。讓我們再回到GOF，Eric Gamma作為先驅參與了Eclipse的設計。

雖然Eclipse中，GOF23種設計模式的痕跡已不再清晰，但Eclipse的生機勃勃說明了“模式”未死。

下一篇，我會循著GOF的足跡，帶著亞歷山大的精神繼續設計模式之旅。

附錄

• DESIGN PATTERNS CRITICISM
• Rethinking Design Patterns
• "Design Patterns" Aren't

• Design Patterns: When Breaking The Rules Is OK

?

轉載于:https://www.cnblogs.com/printj/p/3875543.html

總結

以上是生活随笔為你收集整理的PrintJ的设计模式之旅——1.模式之父的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。