# 從招式與內功談起——設計模式概述(三)
### 1.3 設計模式有什么用
下面我們來回答最后一個問題:設計模式到底有什么用?簡單來說,設計模式至少有如下幾個用途:
(1) 設計模式來源眾多專家的經驗和智慧,它們是從許多優秀的軟件系統中總結出的成功的、能夠實現可維護性復用的設計方案,使用這些方案將可以讓我們避免做一些重復性的工作,也許我們冥思苦想得到的一個“自以為很了不起”的設計方案其實就是某一個設計模式。在時間就是金錢的今天,設計模式無疑會為有助于我們提高開發和設計效率,但它不保證一定會提高,微笑。
(2) 設計模式提供了一套通用的設計詞匯和一種通用的形式來方便開發人員之間溝通和交流,使得設計方案更加通俗易懂。交流通常很耗時,任何有助于提高交流效率的東西都可以為我們節省不少時間。無論你使用哪種編程語言,做什么類型的項目,甚至你處于一個國際化的開發團隊,當面對同一個設計模式時,你和別人的理解并無二異,因為設計模式是跨語言、跨平臺、跨應用、跨國界的,微笑。
(3) 大部分設計模式都兼顧了系統的可重用性和可擴展性,這使得我們可以更好地重用一些已有的設計方案、功能模塊甚至一個完整的軟件系統,避免我們經常做一些重復的設計、編寫一些重復的代碼。此外,隨著軟件規模的日益增大,軟件壽命的日益變長,系統的可維護性和可擴展性也越來越重要,許多設計模式將有助于提高系統的靈活性和可擴展性,讓我們在不修改或者少修改現有系統的基礎上增加、刪除或者替換功能模塊。如果一點設計模式都不懂,我想要做到這一點恐怕還是很困難的,微笑。
(4) 合理使用設計模式并對設計模式的使用情況進行文檔化,將有助于別人更快地理解系統。如果某一天因為升職或跳槽等原因,別人接手了你的項目,只要他也懂設計模式,我想他應該能夠很快理解你的設計思路和實現方案,讓你升職無后患之憂,跳槽也心安理得,何樂而不為呢?微笑。
(5) 最后一點對初學者很重要,學習設計模式將有助于初學者更加深入地理解面向對象思想,讓你知道:如何將代碼分散在幾個不同的類中?為什么要有“接口”?何謂針對抽象編程?何時不應該使用繼承?如果不修改源代碼增加新功能?同時還讓你能夠更好地閱讀和理解現有類庫(如JDK)與其他系統中的源代碼,讓你早點脫離面向對象編程的“菜鳥期”,微笑。
### 1.4 個人觀點
作為設計模式的忠實粉絲和推廣人員,在正式學習設計模式之前,我結合多年的模式應用和教育培訓經驗與大家分享幾點個人的看法,以作參考:
(1) 掌握設計模式并不是件很難的事情,關鍵在于多思考,多實踐,不要聽到人家說懂幾個設計模式就很“牛”,只要用心學習,設計模式也就那么回事,你也可以很“牛”的,一定要有信心。
(2) 在學習每一個設計模式時至少應該掌握如下幾點:這個設計模式的意圖是什么,它要解決一個什么問題,什么時候可以使用它;它是如何解決的,掌握它的結構圖,記住它的關鍵代碼;能夠想到至少兩個它的應用實例,一個生活中的,一個軟件中的;這個模式的優缺點是什么,在使用時要注意什么。當你能夠回答上述所有問題時,恭喜你,你了解一個設計模式了,至于掌握它,那就在開發中去使用吧,用多了你自然就掌握了。
(3) “如果想體驗一下運用模式的感覺,那么最好的方法就是運用它們”。正如在本章最開始所說的,設計模式是“內功心法”,它還是要與“實戰招式”相結合才能夠相得益彰。學習設計模式的目的在于應用,如果不懂如何使用一個設計模式,而只是學過,能夠說出它的用途,繪制它的結構,充其量也只能說你了解這個模式,嚴格一點說:不會在開發中靈活運用一個模式基本上等于沒學。所以一定要做到:少說多做。
(4) 千萬不要濫用模式,不要試圖在一個系統中用上所有的模式,也許有這樣的系統,但至少目前我沒有碰到過。每個模式都有自己的適用場景,不能為了使用模式而使用模式?【怎么理解,大家自己思考,微笑】,濫用模式不如不用模式,因為濫用的結果得不到“藝術品”一樣的軟件,很有可能是一堆垃圾代碼。
(5) 如果將設計模式比喻成“三十六計”,那么每一個模式都是一種計策,它為解決某一類問題而誕生,不管這個設計模式的難度如何,使用頻率高不高,我建議大家都應該好好學學,多學一個模式也就意味著你多了“一計”,說不定什么時候一不小心就用上了,微笑。因此,模式學習之路上要不怕困難,勇于挑戰,有的模式雖然難一點,但反復琢磨,反復研讀,應該還是能夠征服的。
(6) 設計模式的“上乘”境界:“手中無模式,心中有模式”。模式使用的最高境界是你已經不知道具體某個設計模式的定義和結構了,但你會靈活自如地選擇一種設計方案【其實就是某個設計模式】來解決某個問題,設計模式已經成為你開發技能的一部分,能夠手到擒來,“內功”與“招式”已渾然一體,要達到這個境界并不是看完某本書或者開發一兩個項目就能夠實現的,它需要不斷沉淀與積累,所以,對模式的學習不要急于求成。
(7) 最后一點來自GoF已故成員、我個人最尊敬和崇拜的軟件工程大師之一John Vlissides的著作《設計模式沉思錄》(Pattern Hatching Design Patterns Applied):模式從不保證任何東西,它不能保證你一定能夠做出可復用的軟件,提高你的生產率,更不能保證世界和平,微笑。模式并不能替代人來完成軟件系統的創造,它們只不過會給那些缺乏經驗但卻具備才能和創造力的人帶來希望。
擴展
John Vlissides(1961-2005),GoF成員,斯坦福大學計算機科學博士,原IBM研究員,因患腦瘤于2005年11月24日(感恩節)病故,享年44歲,為紀念他的貢獻,ACM SIGPLAN特設立John Vlissides獎。
- 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
- 操作復雜對象結構——訪問者模式(一)
- 操作復雜對象結構——訪問者模式(二)
- 操作復雜對象結構——訪問者模式(三)
- 操作復雜對象結構——訪問者模式(四)
- 設計模式趣味學習(復習)
- 設計模式與足球(一)
- 設計模式與足球(二)
- 設計模式與足球(三)
- 設計模式與足球(四)
- 設計模式綜合應用實例
- 多人聯機射擊游戲
- 多人聯機射擊游戲中的設計模式應用(一)
- 多人聯機射擊游戲中的設計模式應用(二)
- 數據庫同步系統
- 設計模式綜合實例分析之數據庫同步系統(一)
- 設計模式綜合實例分析之數據庫同步系統(二)
- 設計模式綜合實例分析之數據庫同步系統(三)