# 從招式與內功談起——設計模式概述(一)
關于金庸小說中到底是招式重要還是內功重要的爭論從未停止,我們在這里并不分析張無忌的九陽神功和令狐沖的獨孤九劍到底哪個更厲害,但我想每個武林人士夢寐以求的應該是既有淋漓的招式又有深厚的內功。看到這里大家可能會產生疑問了?搞什么,討論什么招式與內功,我只是個軟件開發人員。別急,正因為你是軟件開發人員我才跟你談這個,因為我們的軟件開發技術也包括一些招式和內功:Java、C#、C++等編程語言,Eclipse、Visual Studio等開發工具,JSP、ASP.net等開發技術,Struts、Hibernate、JBPM等框架技術,所有這些我們都可以認為是招式;而數據結構、算法、設計模式、重構、軟件工程等則為內功。招式可以很快學會,但是內功的修煉需要更長的時間。我想每一位軟件開發人員也都希望成為一名兼具淋漓招式和深厚內功的“上乘”軟件工程師,而對設計模式的學習與領悟將會讓你“內功”大增,再結合你日益純熟的“招式”,你的軟件開發“功力”一定會達到一個新的境界。既然這樣,還等什么,趕快行動吧。下面就讓我們正式踏上神奇而又美妙的設計模式之旅。

1 設計模式從何而來
在介紹設計模式的起源之前,我們先要了解一下模式的誕生與發展。與很多軟件工程技術一樣,模式起源于建筑領域,畢竟與只有幾十年歷史的軟件工程相比,已經擁有幾千年沉淀的建筑工程有太多值得學習和借鑒的地方。
那么模式是如何誕生的?讓我們先來認識一個人——Christopher Alexander(克里斯托弗.亞歷山大),哈佛大學建筑學博士、美國加州大學伯克利分校建筑學教授、加州大學伯克利分校環境結構研究所所長、美國藝術和科學院院士……頭銜真多,微笑,不過他還有一個“昵稱”——模式之父(The father of patterns)。Christopher Alexander博士及其研究團隊用了約20年的時間,對住宅和周邊環境進行了大量的調查研究和資料收集工作,發現人們對舒適住宅和城市環境存在一些共同的認同規律,Christopher Alexander在著作A Pattern Language: Towns, Buildings, Construction中把這些認同規律歸納為253個模式,對每一個模式(Pattern)都從Context(前提條件)、Theme或Problem(目標問題)、 Solution(解決方案)三個方面進行了描述,并給出了從用戶需求分析到建筑環境結構設計直至經典實例的過程模型。
在Christopher Alexander的另一部經典著作《建筑的永恒之道》中,他給出了關于模式的定義:
每個模式都描述了一個在我們的環境中不斷出現的問題,然后描述了該問題的解決方案的核心,通過這種方式,我們可以無數次地重用那些已有的成功的解決方案,無須再重復相同的工作。這個定義可以簡單地用一句話表示:
模式是在特定環境下人們解決某類重復出現問題的一套成功或有效的解決方案。【A pattern is a successful or efficient solution to a recurring problem within a context】
1990年,軟件工程界開始關注ChristopherAlexander等在這一住宅、公共建筑與城市規劃領域的重大突破。最早將模式的思想引入軟件工程方法學的是1991-1992年以“四人組(Gang of Four,簡稱GoF,分別是Erich Gamma, Richard Helm, Ralph Johnson和John Vlissides)”自稱的四位著名軟件工程學者,他們在1994年歸納發表了23種在軟件開發中使用頻率較高的設計模式,旨在用模式來統一溝通面向對象方法在分析、設計和實現間的鴻溝。
GoF將模式的概念引入軟件工程領域,這標志著軟件模式的誕生。軟件模式(Software Patterns)是將模式的一般概念應用于軟件開發領域,即軟件開發的總體指導思路或參照樣板。軟件模式并非僅限于設計模式,還包括架構模式、分析模式和過程模式等,實際上,在軟件開發生命周期的每一個階段都存在著一些被認同的模式。
軟件模式是在軟件開發中某些可重現問題的一些有效解決方法,軟件模式的基礎結構主要由四部分構成,包括問題描述【待解決的問題是什么】、前提條件【在何種環境或約束條件下使用】、解法【如何解決】和效果【有哪些優缺點】,如圖1-1所示:

圖1-1 軟件模式基本結構
軟件模式與具體的應用領域無關,也就是說無論你從事的是移動應用開發、桌面應用開發、Web應用開發還是嵌入式軟件的開發,都可以使用軟件模式。
在軟件模式中,設計模式是研究最為深入的分支,設計模式用于在特定的條件下為一些重復出現的軟件設計問題提供合理的、有效的解決方案,它融合了眾多專家的設計經驗,已經在成千上萬的軟件中得以應用。 1995年, GoF將收集和整理好的23種設計模式匯編成Design Patterns: Elements of Reusable Object-Oriented Software【《設計模式:可復用面向對象軟件的基礎》】一書,該書的出版也標志著設計模式正式成為面向對象(Object Oriented)軟件工程的一個重要研究分支。

從1995年至今,無論是在大型API或框架(如JDK、.net Framework等)、輕量級框架(如Struts、Spring、 Hibernate、JUnit等)、還是應用軟件的開發中,設計模式都得到了廣泛的應用。如果你正在從事面向對象開發或正準備從事面向對象開發,無論你是使用Java、C#、Objective-C、VB.net、Smalltalk等純面向對象編程語言,還是使用C++、PHP、Delphi、JavaScript等可支持面向對象編程的語言,如果你一點設計模式也不懂,我可以毫不夸張的說:你真的out了。
- Introduction
- 基礎知識
- 設計模式概述
- 從招式與內功談起——設計模式概述(一)
- 從招式與內功談起——設計模式概述(二)
- 從招式與內功談起——設計模式概述(三)
- 面向對象設計原則
- 面向對象設計原則之單一職責原則
- 面向對象設計原則之開閉原則
- 面向對象設計原則之里氏代換原則
- 面向對象設計原則之依賴倒轉原則
- 面向對象設計原則之接口隔離原則
- 面向對象設計原則之合成復用原則
- 面向對象設計原則之迪米特法則
- 六個創建型模式
- 簡單工廠模式-Simple Factory Pattern
- 工廠三兄弟之簡單工廠模式(一)
- 工廠三兄弟之簡單工廠模式(二)
- 工廠三兄弟之簡單工廠模式(三)
- 工廠三兄弟之簡單工廠模式(四)
- 工廠方法模式-Factory Method Pattern
- 工廠三兄弟之工廠方法模式(一)
- 工廠三兄弟之工廠方法模式(二)
- 工廠三兄弟之工廠方法模式(三)
- 工廠三兄弟之工廠方法模式(四)
- 抽象工廠模式-Abstract Factory Pattern
- 工廠三兄弟之抽象工廠模式(一)
- 工廠三兄弟之抽象工廠模式(二)
- 工廠三兄弟之抽象工廠模式(三)
- 工廠三兄弟之抽象工廠模式(四)
- 工廠三兄弟之抽象工廠模式(五)
- 單例模式-Singleton Pattern
- 確保對象的唯一性——單例模式 (一)
- 確保對象的唯一性——單例模式 (二)
- 確保對象的唯一性——單例模式 (三)
- 確保對象的唯一性——單例模式 (四)
- 確保對象的唯一性——單例模式 (五)
- 原型模式-Prototype Pattern
- 對象的克隆——原型模式(一)
- 對象的克隆——原型模式(二)
- 對象的克隆——原型模式(三)
- 對象的克隆——原型模式(四)
- 建造者模式-Builder Pattern
- 復雜對象的組裝與創建——建造者模式(一)
- 復雜對象的組裝與創建——建造者模式(二)
- 復雜對象的組裝與創建——建造者模式(三)
- 七個結構型模式
- 適配器模式-Adapter Pattern
- 不兼容結構的協調——適配器模式(一)
- 不兼容結構的協調——適配器模式(二)
- 不兼容結構的協調——適配器模式(三)
- 不兼容結構的協調——適配器模式(四)
- 橋接模式-Bridge Pattern
- 處理多維度變化——橋接模式(一)
- 處理多維度變化——橋接模式(二)
- 處理多維度變化——橋接模式(三)
- 處理多維度變化——橋接模式(四)
- 組合模式-Composite Pattern
- 樹形結構的處理——組合模式(一)
- 樹形結構的處理——組合模式(二)
- 樹形結構的處理——組合模式(三)
- 樹形結構的處理——組合模式(四)
- 樹形結構的處理——組合模式(五)
- 裝飾模式-Decorator Pattern
- 擴展系統功能——裝飾模式(一)
- 擴展系統功能——裝飾模式(二)
- 擴展系統功能——裝飾模式(三)
- 擴展系統功能——裝飾模式(四)
- 外觀模式-Facade Pattern
- 深入淺出外觀模式(一)
- 深入淺出外觀模式(二)
- 深入淺出外觀模式(三)
- 享元模式-Flyweight Pattern
- 實現對象的復用——享元模式(一)
- 實現對象的復用——享元模式(二)
- 實現對象的復用——享元模式(三)
- 實現對象的復用——享元模式(四)
- 實現對象的復用——享元模式(五)
- 代理模式-Proxy Pattern
- 設計模式之代理模式(一)
- 設計模式之代理模式(二)
- 設計模式之代理模式(三)
- 設計模式之代理模式(四)
- 十一個行為型模式
- 職責鏈模式-Chain of Responsibility Pattern
- 請求的鏈式處理——職責鏈模式(一)
- 請求的鏈式處理——職責鏈模式(二)
- 請求的鏈式處理——職責鏈模式(三)
- 請求的鏈式處理——職責鏈模式(四)
- 命令模式-Command Pattern
- 請求發送者與接收者解耦——命令模式(一)
- 請求發送者與接收者解耦——命令模式(二)
- 請求發送者與接收者解耦——命令模式(三)
- 請求發送者與接收者解耦——命令模式(四)
- 請求發送者與接收者解耦——命令模式(五)
- 請求發送者與接收者解耦——命令模式(六)
- 解釋器模式-Interpreter Pattern
- 自定義語言的實現——解釋器模式(一)
- 自定義語言的實現——解釋器模式(二)
- 自定義語言的實現——解釋器模式(三)
- 自定義語言的實現——解釋器模式(四)
- 自定義語言的實現——解釋器模式(五)
- 自定義語言的實現——解釋器模式(六)
- 迭代器模式-Iterator Pattern
- 遍歷聚合對象中的元素——迭代器模式(一)
- 遍歷聚合對象中的元素——迭代器模式(二)
- 遍歷聚合對象中的元素——迭代器模式(三)
- 遍歷聚合對象中的元素——迭代器模式(四)
- 遍歷聚合對象中的元素——迭代器模式(五)
- 遍歷聚合對象中的元素——迭代器模式(六)
- 中介者模式-Mediator Pattern
- 協調多個對象之間的交互——中介者模式(一)
- 協調多個對象之間的交互——中介者模式(二)
- 協調多個對象之間的交互——中介者模式(三)
- 協調多個對象之間的交互——中介者模式(四)
- 協調多個對象之間的交互——中介者模式(五)
- 備忘錄模式-Memento Pattern
- 撤銷功能的實現——備忘錄模式(一)
- 撤銷功能的實現——備忘錄模式(二)
- 撤銷功能的實現——備忘錄模式(三)
- 撤銷功能的實現——備忘錄模式(四)
- 撤銷功能的實現——備忘錄模式(五)
- 觀察者模式-Observer Pattern
- 對象間的聯動——觀察者模式(一)
- 對象間的聯動——觀察者模式(二)
- 對象間的聯動——觀察者模式(三)
- 對象間的聯動——觀察者模式(四)
- 對象間的聯動——觀察者模式(五)
- 對象間的聯動——觀察者模式(六)
- 狀態模式-State Pattern
- 處理對象的多種狀態及其相互轉換——狀態模式(一)
- 處理對象的多種狀態及其相互轉換——狀態模式(二)
- 處理對象的多種狀態及其相互轉換——狀態模式(三)
- 處理對象的多種狀態及其相互轉換——狀態模式(四)
- 處理對象的多種狀態及其相互轉換——狀態模式(五)
- 處理對象的多種狀態及其相互轉換——狀態模式(六)
- 策略模式-Strategy Pattern
- 算法的封裝與切換——策略模式(一)
- 算法的封裝與切換——策略模式(二)
- 算法的封裝與切換——策略模式(三)
- 算法的封裝與切換——策略模式(四)
- 模板方法模式-Template Method Pattern
- 模板方法模式深度解析(一)
- 模板方法模式深度解析(二)
- 模板方法模式深度解析(三)
- 訪問者模式-Visitor Pattern
- 操作復雜對象結構——訪問者模式(一)
- 操作復雜對象結構——訪問者模式(二)
- 操作復雜對象結構——訪問者模式(三)
- 操作復雜對象結構——訪問者模式(四)
- 設計模式趣味學習(復習)
- 設計模式與足球(一)
- 設計模式與足球(二)
- 設計模式與足球(三)
- 設計模式與足球(四)
- 設計模式綜合應用實例
- 多人聯機射擊游戲
- 多人聯機射擊游戲中的設計模式應用(一)
- 多人聯機射擊游戲中的設計模式應用(二)
- 數據庫同步系統
- 設計模式綜合實例分析之數據庫同步系統(一)
- 設計模式綜合實例分析之數據庫同步系統(二)
- 設計模式綜合實例分析之數據庫同步系統(三)