本文預(yù)覽：

• 設(shè)計模式簡介
  • 軟件設(shè)計固有的復(fù)雜性
  • 如何解決復(fù)雜性
  • 軟件設(shè)計的目標
• 設(shè)計模式六大原則
• 組件協(xié)作模式
  • 模板方法
  • 策略模式
  • 觀察者模式
• 裝飾模式
• 橋模式

設(shè)計模式簡介

設(shè)計模式

歷史性著作《設(shè)計模式:可復(fù)用面向?qū)ο筌?件的基礎(chǔ)》一書中 述了23種經(jīng)典面向?qū)ο?設(shè)計模式,創(chuàng)立了模式在軟件設(shè)計中的地位。GoF(GoF is simple of Gang of Four)這本書名聲有多大，幾乎無人不知無人不曉，堪稱《九陰真經(jīng)》心法，既然是心法，那可不是一朝一夕就可練成的。在軟件設(shè)計界，此書幾乎人手一本，但是，然并卵，此書閑置率也堪稱絕世經(jīng)典，即使此書讀了上百遍，依然不能在實際應(yīng)用中有所建樹，這就是心法。

軟件設(shè)計固有的復(fù)雜性

建筑商從來不會去想給一棟已建好的100層高的 樓房底下再新修一個小地下室——這樣做花費極 大而且注定要失敗。然而令人驚奇的是,軟件系統(tǒng)的用戶在要求作出類似改變時卻不會仔細考慮, 而且他們認為這只是需要簡單編程的事。
——Object-Oriented Analysis and Design with Applications

軟件設(shè)計為什么那么復(fù)雜，很多時候項目經(jīng)理說要添加一個需求，程序說加不了，于是經(jīng)理說，不就是改兩行代碼嗎。其實，在很多情況下相當于，我蓋好了一棟大樓
經(jīng)理：我要加一個地下室。
工程師：加不了。
經(jīng)理：不就是加一個地下室嗎？
顯然沒有這么無知的經(jīng)理，但是在軟件領(lǐng)域，確實是有這么無知的產(chǎn)品經(jīng)理，因為不是所有的人都懂得軟件設(shè)計，但是幾乎所有的人都知道怎么蓋大樓。

那么軟件設(shè)計為什么如此復(fù)雜？
根本原因在于變化。一是，客戶需求反復(fù)無常，一會這樣一會那樣，剛蓋好三層樓拆掉重蓋也不是沒有可能。二是，技術(shù)團隊變化，資本主義社會不再像美好的社會主義，市場經(jīng)濟下，人才流動是常常發(fā)生的事，總工程師帶著小弟去創(chuàng)業(yè)了，如果之前沒有完善的文檔，那么，誰來接手這個燙手的山芋。三是，技術(shù)平臺變化，十年前誰能想到，我們現(xiàn)在人手一部智能手機，原來花了幾百萬開發(fā)的跑在windows上的程序能不能跑在iphone上？四是，市場環(huán)境變化，媽了個蛋的，誰曾想到，半年前確定的開發(fā)一套造自行車的ERP系統(tǒng)，今天你說我要轉(zhuǎn)行去做房地產(chǎn)，把原來的系統(tǒng)改成房地產(chǎn)ERP系統(tǒng)。
變化，這才是軟件設(shè)計領(lǐng)域要解決的最頭等的大事，試想，蓋好的大樓，誰會拆了加一個地下室，但是軟件設(shè)計領(lǐng)域會，一個好的架構(gòu)，不止能加地下室，還能把大樓改造成鋼鐵俠(純扯淡)。

如何解決復(fù)雜性

面對一個一臉懵逼的問題，我們?nèi)绾蚊鎸Γ?/p>

• 分解
• 抽象

分解：一個復(fù)雜的問題，人類如何面對，分解成一個個小的，簡單的問題，逐個擊破。這就是人類解決問題最基本的方法。
抽象：其實一切高于自然的東西都是抽象出來的，社會、法律、制度......這是人類統(tǒng)治世界的終極大招。由于不能掌握全部的復(fù)雜對象,我們選擇忽視它的非本質(zhì)細節(jié), 而去處理泛化和理想化了的對象模型。
這兩種方法是通用方法，研究數(shù)學(xué)也是用到這兩種方法，一種是泛化(抽象)，一種是特化(分解)。

軟件設(shè)計的目標

什么是好的軟件設(shè)計，軟件設(shè)計的金科玉律：復(fù)用

設(shè)計模式六大原則

六大設(shè)計原則是心法的心法，所有設(shè)計模式都是遵循這六大原則演變來的，雖然晦澀難懂，但是既然是心法的心法，即使不懂怎么用，背出來裝裝逼也是可以的。

• 依賴倒置原則

• 高層模塊(穩(wěn)定)不應(yīng)依賴低層(變化)模塊，二者都應(yīng)依賴于抽象(穩(wěn)定)。

• 抽象(穩(wěn)定)不應(yīng)依賴實現(xiàn)細節(jié)(變化)，實現(xiàn)細節(jié)應(yīng)該依賴抽象(穩(wěn)定)。

• 開放封閉原則

  • 對擴展開放，對更改封閉
  • 類模塊應(yīng)該是可擴展的，但是不可修改

• 單一職責(zé)原則

• 一個類應(yīng)該只有一個引起它變化的原因

• 變化的方向隱含著類的責(zé)任

• Liskov替換原則

• 子類必須能夠替換它們的基類(IS-A)

• 繼承表達類型抽象

• 接口隔離原則

• 不應(yīng)該強迫客戶程序依賴它們不用的方法

• 接口應(yīng)該小而完備

• 優(yōu)先使用對象組合,而不是類繼承

• 繼承在某種程度上破壞了封裝性,子類父類耦合度高

• 而對象組合則只要求被組合的對象具有良好定義的接口,耦合 度低

重構(gòu)獲得模式

看完這六大原則，不管是不是理解了，是不是在寫代碼的時候直接就可以用上了呢？一副都起開，老衲要開始裝逼了的樣子。然而并不是，設(shè)計模式的應(yīng)用不宜先入為主,一上來就使用設(shè)計模式是對設(shè)計 模式的最大誤用。沒有一步到位的設(shè)計模式。敏捷軟件開發(fā)實踐提倡的“Refactoring to Patterns”是目前普遍公認的最好的使用設(shè)計模式的方法。

現(xiàn)代軟件設(shè)計的特征是“需求的頻繁變化”。設(shè)計模式的要點是 “尋找變化點,然后在變化點處應(yīng)用設(shè)計模式,從而來更好地應(yīng)對 需求的變化”.“什么時候、什么地點應(yīng)用設(shè)計模式”比“理解設(shè)計 模式結(jié)構(gòu)本身”更為重要。

我相信看到這的你，是懵逼的，說了這么久，設(shè)計模式不是一樣來就用的(除非你對業(yè)務(wù)模型非常了解，和之前做過的項目一樣的)，而是通過重構(gòu)。

關(guān)于重構(gòu)的經(jīng)典書籍

重構(gòu)關(guān)鍵技法

• 靜態(tài) 動態(tài)
• 早綁定 晚綁定
• 繼承 組合
• 編譯時依賴 運行時依賴
• 緊耦合 松耦合

組件協(xié)作模式

現(xiàn)代軟件專業(yè)分工后的第一個結(jié)果是框架與應(yīng)用程序的劃分，組件協(xié)作模式通過晚綁定，來實現(xiàn)框架與應(yīng)用程序之間的松耦合，是二者之間協(xié)作時的常用模式。

典型模式

• 模板方法
• 策略模式
• 觀察者模式

關(guān)于這些模式的代碼演示和解釋見下面鏈接:
模板方法
策略模式
觀察者模式
這幾篇是我讀過的算是解釋的非常清楚簡介的文章了，代碼有些是用java寫的，可能作者比較懶，直接抄的《大話設(shè)計模式》，自己實際寫一遍還是很有收獲的。