今日總結1.2

新晋软工小白發表於2024-09-16

一、軟體設計模式的產生背景
“設計模式”這個術語最初並不是出現在軟體設計中,而是被用於建築領域的設計中。

1977 年,美國著名建築大師、加利福尼亞大學伯克利分校環境結構中心主任克里斯托夫·亞歷山大(Christopher Alexander)在他的著作《建築模式語言:城鎮、建築、構造(A Pattern Language: Towns Building Construction)中描述了一些常見的建築設計問題,並提出了 253 種關於對城鎮、鄰里、住宅、花園和房間等進行設計的基本模式。

1979 年他的另一部經典著作《建築的永恆之道》(The Timeless Way of Building)進一步強化了設計模式的思想,為後來的建築設計指明瞭方向。

1987 年,肯特·貝克(Kent Beck)和沃德·坎寧安(Ward Cunningham)首先將克里斯托夫·亞歷山大的模式思想應用在 Smalltalk 中的圖形使用者介面的生成中,但沒有引起軟體界的關注。

直到 1990 年,軟體工程界才開始研討設計模式的話題,後來召開了多次關於設計模式的研討會。

1995 年,艾瑞克·伽馬(ErichGamma)、理査德·海爾姆(Richard Helm)、拉爾夫·約翰森(Ralph Johnson)、約翰·威利斯迪斯(John Vlissides)等 4 位作者合作出版了《設計模式:可複用物件導向軟體的基礎》(Design Patterns: Elements of Reusable Object-Oriented Software)一書,在本教程中收錄了 23 個設計模式,這是設計模式領域裡程碑的事件,導致了軟體設計模式的突破。這 4 位作者在軟體開發領域裡也以他們的“四人組”(Gang of Four,GoF)匿名著稱。

直到今天,狹義的設計模式還是本教程中所介紹的 23 種經典設計模式。

二、軟體設計模式的概念與意義
有關軟體設計模式的定義很多,有些從模式的特點來說明,有些從模式的作用來說明。本教程給出的定義是大多數學者公認的,從以下兩個方面來說明。

1. 軟體設計模式的概念
軟體設計模式(Software Design Pattern),又稱設計模式,是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。它描述了在軟體設計過程中的一些不斷重複發生的問題,以及該問題的解決方案。也就是說,它是解決特定問題的一系列套路,是前輩們的程式碼設計經驗的總結,具有一定的普遍性,可以反覆使用。其目的是為了提高程式碼的可重用性、程式碼的可讀性和程式碼的可靠性。

2. 學習設計模式的意義
設計模式的本質是物件導向設計原則的實際運用,是對類的封裝性、繼承性和多型性以及類的關聯關係和組合關係的充分理解。正確使用設計模式具有以下優點。

可以提高程式設計師的思維能力、程式設計能力和設計能力。
使程式設計更加標準化、程式碼編制更加工程化,使軟體開發效率大大提高,從而縮短軟體的開發週期。
使設計的程式碼可重用性高、可讀性強、可靠性高、靈活性好、可維護性強。

當然,軟體設計模式只是一個引導。在具體的軟體幵發中,必須根據設計的應用系統的特點和要求來恰當選擇。對於簡單的程式開發,苛能寫一個簡單的演算法要比引入某種設計模式更加容易。但對大專案的開發或者框架設計,用設計模式來組織程式碼顯然更好。

三、23 種設計模式的分類和功能
1. 根據目的來分
根據模式是用來完成什麼工作來劃分,這種方式可分為建立型模式、結構型模式和行為型模式 3 種。

建立型模式:用於描述“怎樣建立物件”,它的主要特點是“將物件的建立與使用分離”。GoF 中提供了單例、原型、工廠方法、抽象工廠、建造者等 5 種建立型模式。
結構型模式:用於描述如何將類或物件按某種佈局組成更大的結構,GoF 中提供了代理、介面卡、橋接、裝飾、外觀、享元、組合等 7 種結構型模式。
行為型模式:用於描述類或物件之間怎樣相互協作共同完成單個物件都無法單獨完成的任務,以及怎樣分配職責。GoF 中提供了模板方法、策略、命令、職責鏈、狀態、觀察者、中介者、迭代器、訪問者、備忘錄、直譯器等 11 種行為型模式。
序號 模式 & 描述 包括
1 建立型模式
這些設計模式提供了一種在建立物件的同時隱藏建立邏輯的方式,而不是使用 new 運算子直接例項化物件。這使得程式在判斷針對某個給定例項需要建立哪些物件時更加靈活。
工廠模式(Factory Pattern)
抽象工廠模式(Abstract Factory Pattern)
單例模式(Singleton Pattern)
建造者模式(Builder Pattern)
原型模式(Prototype Pattern)
2 結構型模式
這些設計模式關注類和物件的組合。繼承的概念被用來組合介面和定義組合物件獲得新功能的方式。
介面卡模式(Adapter Pattern)
橋接模式(Bridge Pattern)
過濾器模式(Filter、Criteria Pattern)
組合模式(Composite Pattern)
裝飾器模式(Decorator Pattern)
外觀模式(Facade Pattern)
享元模式(Flyweight Pattern)
代理模式(Proxy Pattern)
3 行為型模式
這些設計模式特別關注物件之間的通訊。
責任鏈模式(Chain of Responsibility Pattern)
命令模式(Command Pattern)
直譯器模式(Interpreter Pattern)
迭代器模式(Iterator Pattern)
中介者模式(Mediator Pattern)
備忘錄模式(Memento Pattern)
觀察者模式(Observer Pattern)
狀態模式(State Pattern)
空物件模式(Null Object Pattern)
策略模式(Strategy Pattern)
模板模式(Template Pattern)
訪問者模式(Visitor Pattern)
4 J2EE 模式
這些設計模式特別關注表示層。這些模式是由 Sun Java Center 鑑定的。
MVC 模式(MVC Pattern)
業務代表模式(Business Delegate Pattern)
組合實體模式(Composite Entity Pattern)
資料訪問物件模式(Data Access Object Pattern)
前端控制器模式(Front Controller Pattern)
攔截過濾器模式(Intercepting Filter Pattern)
服務定位器模式(Service Locator Pattern)
傳輸物件模式(Transfer Object Pattern)
2. 根據作用範圍來分
根據模式是主要用於類上還是主要用於物件上來分,這種方式可分為類模式和物件模式兩種。

類模式:用於處理類與子類之間的關係,這些關係透過繼承來建立,是靜態的,在編譯時刻便確定下來了。GoF中的工廠方法、(類)介面卡、模板方法、直譯器屬於該模式。
物件模式:用於處理物件之間的關係,這些關係可以透過組合或聚合來實現,在執行時刻是可以變化的,更具動態性。GoF 中除了以上 4 種,其他的都是物件模式。
範圍\目的 建立型模式 結構型模式 行為型模式
類模式 工廠方法 (類)介面卡 模板方法、直譯器
物件模式 單例
原型
抽象工廠
建造者 代理
(物件)介面卡
橋接
裝飾
外觀
享元
組合 策略
命令
職責鏈
狀態
觀察者
中介者
迭代器
訪問者
備忘錄
3. 23種設計模式的功能
單例(Singleton)模式:某個類只能生成一個例項,該類提供了一個全域性訪問點供外部獲取該例項,其擴充是有限多例模式。
原型(Prototype)模式:將一個物件作為原型,透過對其進行復制而克隆出多個和原型類似的新例項。
工廠方法(Factory Method)模式:定義一個用於建立產品的介面,由子類決定生產什麼產品。
抽象工廠(AbstractFactory)模式:提供一個建立產品族的介面,其每個子類可以生產一系列相關的產品。
建造者(Builder)模式:將一個複雜物件分解成多個相對簡單的部分,然後根據不同需要分別建立它們,最後構建成該複雜物件。
代理(Proxy)模式:為某物件提供一種代理以控制對該物件的訪問。即客戶端透過代理間接地訪問該物件,從而限制、增強或修改該物件的一些特性。
介面卡(Adapter)模式:將一個類的介面轉換成客戶希望的另外一個介面,使得原本由於介面不相容而不能一起工作的那些類能一起工作。
橋接(Bridge)模式:將抽象與實現分離,使它們可以獨立變化。它是用組合關係代替繼承關係來實現,從而降低了抽象和實現這兩個可變維度的耦合度。
裝飾(Decorator)模式:動態的給物件增加一些職責,即增加其額外的功能。
外觀(Facade)模式:為多個複雜的子系統提供一個一致的介面,使這些子系統更加容易被訪問。
享元(Flyweight)模式:運用共享技術來有效地支援大量細粒度物件的複用。
組合(Composite)模式:將物件組合成樹狀層次結構,使使用者對單個物件和組合物件具有一致的訪問性。
模板方法(TemplateMethod)模式:定義一個操作中的演算法骨架,而將演算法的一些步驟延遲到子類中,使得子類可以不改變該演算法結構的情況下重定義該演算法的某些特定步驟。
策略(Strategy)模式:定義了一系列演算法,並將每個演算法封裝起來,使它們可以相互替換,且演算法的改變不會影響使用演算法的客戶。
命令(Command)模式:將一個請求封裝為一個物件,使發出請求的責任和執行請求的責任分割開。
職責鏈(Chain of Responsibility)模式:把請求從鏈中的一個物件傳到下一個物件,直到請求被響應為止。透過這種方式去除物件之間的耦合。
狀態(State)模式:允許一個物件在其內部狀態發生改變時改變其行為能力。
觀察者(Observer)模式:多個物件間存在一對多關係,當一個物件發生改變時,把這種改變通知給其他多個物件,從而影響其他物件的行為。
中介者(Mediator)模式:定義一箇中介物件來簡化原有物件之間的互動關係,降低系統中物件間的耦合度,使原有物件之間不必相互瞭解。
迭代器(Iterator)模式:提供一種方法來順序訪問聚合物件中的一系列資料,而不暴露聚合物件的內部表示。
訪問者(Visitor)模式:在不改變集合元素的前提下,為一個集合中的每個元素提供多種訪問方式,即每個元素有多個訪問者物件訪問。
備忘錄(Memento)模式:在不破壞封裝性的前提下,獲取並儲存一個物件的內部狀態,以便以後恢復它。
直譯器(Interpreter)模式:提供如何定義語言的文法,以及對語言句子的解釋方法,即直譯器。