設計模式回顧系列之總體介紹
1. 背景與介紹
設計模式是經過反復使用、經過分類的代碼總結。設計模式的目的是提高代碼可重用性和可靠性,並使代碼條理清晰、易於理解、易於維護。
設計模式描述了在各種情況下,要選擇什麽樣的方案來解決問題。設計模式通常以類和對象來描述其中的關系和相互作用,換句話就是在設計模式裏,這些類和普通的類沒有區別,只是它們的相互作用形成了各種設計模式,並解決了很多現實性的問題。
設計模式能使不穩定依賴於相對穩定、具體依賴於相對抽象,避免會引起麻煩的緊耦合,以增強軟件設計面對並適應變化的能力。
設計模式是對面向對象的絕佳應用,它提供了眾多不斷重復發生在我們周圍的問題的解決方案。學習設計模式可以更好的理解面向對象的內容,同時面向對象也為設計模式提供了很好的理論基礎,在學習的過程中,會接觸到很多面向對象的相關應用。
2. 設計原則
- 單一職責原則 (Single Responsiblity Principle SRP)
- 開閉原則(Open Closed Principle,OCP)
- 模塊應對擴展開放,而對修改關閉。直白點說就是,模塊應盡量在不修改原代碼的情況下進行擴展
- 裏氏代換原則(Liskov Substitution Principle,LSP)
- 如果調用的是父類的話,那麽換成子類也完全可以運行
- 依賴倒轉原則(Dependency Inversion Principle,DIP)
- 把父類都替換成它的子類,而不會導致程序的行為發聲變化
- 接口隔離原則(Interface Segregation Principle,
- 合成/聚合復用原則(Composite/Aggregate Reuse Principle,CARP)
- 最小知識原則(Principle of Least Knowledge,PLK,也叫迪米特法則)
- 一個對象應對其他對象有盡可能少的了解,也就是說要做好信息的隱藏,這個原則可以更多的從封裝的角度去思考,包括方法與屬性的設計。
3. 分類
根據GOF《設計模式》一書,設計模式分為三個大類,共23種。
以下改編自維基百科,另外再附一張總覽圖,方便有個總體的概念
模式名稱 |
描述 |
|
創建型模式 |
||
工廠方法模式 |
定義一個接口用於創建對象,但是讓子類決定初始化哪個類。工廠方法把一個類的初始化下放到子類。 |
|
抽象工廠模式 |
為一個產品族提供了統一的創建接口。當需要這個產品族的某一系列的時候,可以從抽象工廠中選出相應的系列創建一個具體的工廠類。 |
|
單例模式 |
確保一個類只有一個實例,並提供對該實例的全局訪問。 |
|
生成器模式 |
將一個復雜對象的構建與它的表示分離,使得同樣的構建過程可以創建不同的表示。 |
|
原型模式 |
用原型實例指定創建對象的種類,並且通過拷貝這些原型,創建新的對象。 |
|
結構型模式 |
||
適配器模式 |
將某個類的接口轉換成客戶端期望的另一個接口表示。適配器模式可以消除由於接口不匹配所造成的類兼容性問題。 |
|
橋接模式 |
將一個抽象與實現解耦,以便兩者可以獨立的變化。 |
|
組合模式 |
把多個對象組成樹狀結構來表示局部與整體,這樣用戶可以一樣的對待單個對象和對象的組合。 |
|
修飾模式 |
向某個對象動態地添加更多的功能。修飾模式是除類繼承外另一種擴展功能的方法。 |
|
外觀模式 |
為子系統中的一組接口提供一個一致的界面, 外觀模式定義了一個高層接口,這個接口使得這一子系統更加容易使用。 |
|
享元模式 |
通過共享以便有效的支持大量小顆粒對象。 |
|
代理模式 |
為其他對象提供一個代理以控制對這個對象的訪問。 |
|
行為型模式 |
||
責任鏈模式 |
為解除請求的發送者和接收者之間耦合,而使多個對象都有機會處理這個請求。將這些對象連成一條鏈,並沿著這條鏈傳遞該請求,直到有一個對象處理它。 |
|
命令模式 |
將一個請求封裝為一個對象,從而使你可用不同的請求對客戶進行參數化;對請求排隊或記錄請求日誌,以及支持可取消的操作。 |
|
解釋器模式 |
給定一個語言, 定義它的文法的一種表示,並定義一個解釋器, 該解釋器使用該表示來解釋語言中的句子。 |
|
叠代器模式 |
提供一種方法順序訪問一個聚合對象中各個元素, 而又不需暴露該對象的內部表示。 |
|
中介者模式 |
包裝了一系列對象相互作用的方式,使得這些對象不必相互明顯作用,從而使它們可以松散偶合。當某些對象之間的作用發生改變時,不會立即影響其他的一些對象之間的作用,保證這些作用可以彼此獨立的變化。 |
|
備忘錄模式 |
備忘錄對象是一個用來存儲另外一個對象內部狀態的快照的對象。備忘錄模式的用意是在不破壞封裝的條件下,將一個對象的狀態捉住,並外部化,存儲起來,從而可以在將來合適的時候把這個對象還原到存儲起來的狀態。 |
|
觀察者模式 |
在對象間定義一個一對多的聯系性,由此當一個對象改變了狀態,所有其他相關的對象會被通知並且自動刷新。 |
|
狀態模式 |
讓一個對象在其內部狀態改變的時候,其行為也隨之改變。狀態模式需要對每一個系統可能獲取的狀態創立一個狀態類的子類。當系統的狀態變化時,系統便改變所選的子類。 |
|
策略模式 |
定義一個算法的系列,將其各個分裝,並且使他們有交互性。策略模式使得算法在用戶使用的時候能獨立的改變。 |
|
模板方法模式 |
模板方法模式準備一個抽象類,將部分邏輯以具體方法及具體構造子類的形式實現,然後聲明一些抽象方法來迫使子類實現剩余的邏輯。不同的子類可以以不同的方式實現這些抽象方法,從而對剩余的邏輯有不同的實現。先構建一個頂級邏輯框架,而將邏輯的細節留給具體的子類去實現。 |
|
訪問者模式 |
封裝一些施加於某種數據結構元素之上的操作。一旦這些操作需要修改,接受這個操作的數據結構可以保持不變。訪問者模式適用於數據結構相對未定的系統,它把數據結構和作用於結構上的操作之間的耦合解脫開,使得操作集合可以相對自由的演化。 |
設計模式回顧系列之總體介紹