設計模式（參考《Head First 設計模式》）

阿新 • • 發佈：2018-11-10

設計模式（參考《Head First 設計模式》）

設計模式（Design Pattern）是一套被反覆使用、多數人知曉的、經過分類的、程式碼設計經驗的總結。
使用設計模式的目的：為了程式碼可重用性、讓程式碼更容易被他人理解、保證程式碼可靠性。設計模式使程式碼編寫真正工程化；設計模式是軟體工程的基石脈絡，如同大廈的結構一樣。

1. 設計模式的分類

總體來說設計模式分為三大類：

建立型模式：物件例項化的模式，建立型模式解耦了物件的例項化過程。一共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。

結構型模式：把類或物件結合在一起形成更大的結構，一共七種：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

行為型模式：類和物件如何互動，及劃分責任和演算法，一共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。

其實還有兩類：併發型模式和執行緒池模式。

2. 設計模式的六大原則

總原則：開閉原則（Open Close Principle）

開閉原則就是說對擴充套件開放，對修改關閉。在程式需要進行拓展的時候，不能去修改原有的程式碼，而是要擴充套件原有程式碼，實現一個熱插拔的效果。所以一句話概括就是：為了使程式的擴充套件性好，易於維護和升級。想要達到這樣的效果，我們需要使用介面和抽象類等。

實際上，絕對封閉的系統是不存在的。無論模組是怎麼封閉，到最後，總還是有一些無法封閉的變化。而我們的思路就是：既然不能做到完全封閉，那我們就應該對那些變化封閉，那些變化隔離做出選擇。我們做出選擇，然後將那些無法封閉的變化抽象出來，進行隔離，允許擴充套件，儘可能的減少系統的開發。當系統變化來臨時，我們要及時的做出反應。

我們並不害怕改變的到來。當變化到來時，我們首先需要做的不是修改程式碼，而是儘可能的將變化抽象出來進行隔離，然後進行擴充套件。面對需求的變化，對程式的修改應該是儘可能通過新增程式碼來實現，而不是通過修改程式碼來實現。

實際上，變化或者可能的變化來的越早，抽象就越容易，相對的，程式碼的維護也就越容易；而當專案接近於完成而來的需求變化，則會使抽象變得很困難——這個困難，並不是抽象本身的困難，抽象本身並沒有困難，困難在於系統的架構已經完成，修改牽扯的方面太多而使得抽象工作變得很困難。

2.1 單一職責原則

不要存在多於一個導致類變更的原因，也就是說每個類應該實現單一的職責，如若不然，就應該把類拆分。

2.2 里氏替換原則（Liskov Substitution Principle）

里氏代換原則(Liskov Substitution Principle LSP)面向物件設計的基本原則之一，他是設計整個繼承體系的原則。里氏代換原則中說，任何基類可以出現的地方，子類一定可以出現。 LSP是繼承複用的基石，只有當衍生類可以替換掉基類，軟體單位的功能不受到影響時，基類才能真正被複用，而衍生類也能夠在基類的基礎上增加新的行為。里氏代換原則是對“開-閉”原則的補充。實現“開-閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現，所以里氏代換原則是對實現抽象化的具體步驟的規範。—— From Baidu 百科

里氏替換原則中，子類對父類的方法儘量不要重寫和過載。因為父類代表了定義好的結構，通過這個規範的介面與外界互動，子類不應該隨便破壞它。換句話說就是所有引用基類的地方必須能透明地使用其子類物件，使用子類替換基類的時候功能不會發生變化；子類在擴充套件父類功能時不能破壞父類原有的功能；

使用繼承時，遵循里氏替換原則：

子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
當子類過載父類方法時，方法的形參要比父類方法的引數更寬鬆
當子類實現父類的抽象方法時，方法的返回值要比父類更嚴格

2.3 依賴倒置原則（Dependence Inversion Principle）

這個是開閉原則的基礎，具體內容：面向介面程式設計，依賴於抽象而不依賴於具體。寫程式碼時用到具體類時，不與具體類互動，而與具體類的上層介面互動。要依賴於抽象，不要依賴於具體；高層模組不應該依賴低層模組，二者都應該依賴其抽象；抽象不應該依賴具體，具體應該依賴抽象；針對介面程式設計，不要針對實現程式設計。在java中，抽象指的是介面或者抽象類，具體就是具體的實現類。工廠方法模式，模板方法模式，迭代器模式都用到了依賴倒置原則。

2.4 介面隔離原則（Interface Segregation Principle）

這個原則的意思是：每個介面中不存在子類用不到卻必須實現的方法，如果不然，就要將介面拆分。使用多個隔離的介面，比使用單個介面（多個介面方法集合到一個的介面）要好。

2.5 迪米特法則（最少知識原則）（Demeter Principle）

就是說：一個類對自己依賴的類知道的越少越好。也就是說無論被依賴的類多麼複雜，都應該將邏輯封裝在方法的內部，通過public方法提供給外部。這樣當被依賴的類變化時，才能最小的影響該類。

最少知識原則的另一個表達方式是：只與直接的朋友通訊。類之間只要有耦合關係，就叫朋友關係。耦合分為依賴、關聯、聚合、組合等。我們稱出現為成員變數、方法引數、方法返回值中的類為直接朋友。區域性變數、臨時變數則不是直接的朋友。我們要求陌生的類不要作為區域性變量出現在類中。成員變數、方法引數、方法返回值中需要的類為直接朋友。類與類之間的關係越密切瞭解越多，耦合度越大。

外觀模式和中介者模式都用到了最少知識原則。