02/06 軟件設計模式

一.創建型模式

抽象工廠 Abstract Factory

構建器 Builder

工廠方法 Factory Method

原型 Prototype

單例模式? Singleton

二.結構型模式

適配器模式? Adapter

橋接模式? Bridge

組合模式? Composite

裝飾者模式? Decorator

外觀模式? Facade

享元模式? Flyweight

代理模式? Proxy

三.行為型模式?Behavioral Patterns

責任鏈模式 Chain of Responsibility?

命令模式 Command?

解釋器模式? Interpreter

迭代器模式 Iterator

中介者模式? Mediator

備忘錄模式? Memento

觀察者模式 Observer?

狀態模式? State

策略模式? Strategy

訪問者模式? Visitor

定義:?設計模式是針對軟件設計中常見問題的可重用解決方案。

作用:?提高代碼的可復用性、可維護性和可擴展性。

分類:

創建型模式:?關注對象的創建過程，例如：工廠方法模式、抽象工廠模式、單例模式等。

結構型模式:?關注類和對象的組合方式，例如：適配器模式、裝飾器模式、代理模式等。

行為型模式:?關注對象之間的通信和職責分配，例如：觀察者模式、策略模式、模板方法模式等。

一.創建型模式

記憶方式：“單身的工人抽煙，想著建筑的原因。”

（５種）單例，工廠，抽象工廠，構建器，原型

抽象工廠 Abstract Factory

旨在提供一個接口，用于創建一系列相關或相互依賴的對象，而無需指定它們的具體類。它允許客戶端代碼在不需要了解具體實現的情況下，這個模式通常用于需要創建多個相關對象的場景，尤其是在產品族的情況下。

（Abstract Factory）：抽象工廠 - 定義創建產品對象的接口。
（Concrete Factory）：具體工廠 - 實現抽象工廠接口，負責創建具體的產品對象。
（Abstract Product）：抽象產品 - 定義產品的接口。
（Product）：具體產品 - 實現抽象產品接口的具體類。

使用場景：

- 當系統需要獨立于其產品的創建、組合和表示時。

- 當系統需要使用多個系列的產品，而不需要依賴于具體的產品實現時。

- 當產品的具體類在運行時決定時。

構建器 Builder

旨在簡化復雜對象的構建過程。它通過將對象的構建過程與其表示分離，使得同樣的構建過程可以創建不同的表示。

Builder（建造者）：定義創建一個產品所需的各個部件的抽象接口。
ConcreteBuilder（具體建造者）：實現Builder接口，構建和裝配各個部件，提供一個方法來返回構建好的產品。
Director（指揮者）：負責管理Builder的構建過程，調用具體建造者的方法來構建產品。
Product（產品）：最終構建的復雜對象。

使用場景：

- 當一個對象的構建過程復雜，且需要多個步驟時。

- 構造過程必須允許已構建對象有不同表示。

工廠方法 Factory Method

定義一個創建對象的接口，讓子類決定實例化哪一個類。

產品接口（Product）：定義了工廠方法所創建的對象的接口。
具體產品（ConcreteProduct）：實現了Product產品接口的具體類。
工廠接口（Creator）：聲明了一個工廠方法，返回一個Product產品對象。
具體工廠（ConcreteCreator）：實現了工廠接口，返回具體產品的實例。

原型 Prototype

它允許通過復制現有的實例來創建新對象，而不是通過直接實例化類。這種模式特別適合于需要創建大量相似對象的場景，能夠提高性能并減少內存消耗。

原型接口（Prototype）：定義一個用于復制自身的接口。
具體原型（ConcretePrototype）：實現原型接口，提供具體的克隆方法。
客戶端（Client）：使用原型實例來創建新的對象。

使用場景

- 當一個類的實例化成本較高時，可以考慮使用原型模式。

- 當需要創建大量相似對象時，原型模式可以有效減少內存消耗。

- 當對象的狀態需要在運行時動態改變時，原型模式提供了靈活性。

單例模式? Singleton

確保一個類只有一個實例，并提供一個全局訪問點。將類的構造函數私有化，并提供一個靜態方法獲取唯一實例。

它常用于需要控制資源訪問的場景，比如數據庫連接、線程池等。

使用場景

- 需要控制資源的訪問，如數據庫連接、線程池等。

- 需要全局訪問的配置類。

- 需要在整個應用中共享的狀態。

二.結構型模式

該類模式主要用于如何組合已有的類和對象以獲得更大的結構，一般借鑒封裝，代理，繼承等概念講一個或多個類或對象進行組合，封裝，以提供同一的外部視圖或新的功能。

記憶：“外橋享組裝代”

適配器模式? Adapter

問題:?需要將一個類的接口轉換成客戶端期望的另一個接口。
解決方案:?創建一個適配器類，將目標接口轉換成適配者接口。
記憶技巧:?適配器就像一個轉接頭，連接不兼容的接口。

1. **目標接口（Target）**：客戶端所期待的接口。
2. **適配者（Adaptee）**：需要被適配的類，通常是已有的類。
3. **適配器（Adapter）**：實現目標接口，并持有一個適配者的實例，將目標接口的方法調用轉發給適配者。

使用場景

- 當你希望使用一些現有的類，但其接口不符合你的需求時。

- 當你想要創建一個可以與多個不兼容接口的類協同工作的系統時。

橋接模式? Bridge

它通過將類的抽象部分與實現部分分離，使得二者可以獨立變化。它是一種對象結構型模式，又稱為柄體模式（Handle and Body ）或接口模式（Interface）這個模式主要用于解決類的層次結構過于復雜的問題

1. **抽象類（Abstraction）**：定義了抽象的接口，并維護一個指向Implementor實現的指針。
2. **擴展抽象類（Refined Abstraction）**：由Abstraction軸向類定義，擴展了抽象類的功能。
3. **實現類接口（Implementor）**：定義了實現部分的接口。這個接口不一定要和Abstraction的接口完全一致，可以完全不同，一把來說，Implementor接口僅提供基本操作，而Abstraction則定義了基于這些基本操作的較高層次的操作
4. **具體實現類（Concrete Implementor）**：實現了實現類接口，提供具體的實現。

適用場景

- 當你需要在多個維度上擴展系統時。

- 當你希望避免在類的層次結構中產生過多的子類時。

- 當你希望在運行時動態切換實現時。

組合模式? Composite

它允許將對象組合成樹形結構以表示“部分-整體”的層次關系。組合模式使得客戶端對單個對象和組合對象的使用具有一致性。

1. **組件（Component）**：定義了葉子和組合對象的共同接口。，所有的葉子節點和組合節點都需要實現這個接口。
2. **葉子節點（Leaf）**：實現了組件Component接口，表示樹的葉子節點。它有自己的行為。
3. **組合節點（Composite）**：實現了組件接口，能夠包含葉子和其他組合對象。它可以包含子節點（其他的葉子或組合節點），并實現了添加和刪除子節點的方法。

適用場景

- 當需要表示對象的部分-整體層次結構時。

- 當希望客戶端忽略組合對象和單個對象的差異時。

裝飾者模式? Decorator

問題:?需要動態地給一個對象添加一些額外的職責。

解決方案:?創建一個裝飾器類，包裝原始對象，并在保持原始對象接口的前提下提供額外的功能。裝飾器就像給蛋糕加奶油，可以不斷添加新的裝飾。

組件接口（Component）：定義一個對象接口，可以給這些對象動態地添加職責。
具體組件（ConcreteComponent）：實現了組件接口的具體對象，定義了被裝飾的對象。
裝飾器（Decorator）：持有一個組件對象的引用，并定義與組件接口一致的接口。
具體裝飾器（ConcreteDecorator）：擴展了裝飾器類，添加了額外的職責。

外觀模式? Facade

它為復雜的子系統提供一個統一的接口，使得子系統更易于使用。通過外觀模式，客戶端可以通過一個簡單的接口與復雜的系統進行交互，而不需要了解系統內部的復雜性。

外觀類（Facade）：提供一個簡單的接口，封裝了復雜的子系統。

子系統類（Subsystem）：實現具體的功能，通常包含多個類，外觀類通過這些類來完成具體的操作。

使用場景

- 當需要為復雜的子系統提供一個簡單的接口時。

- 當需要解耦客戶端與子系統之間的關系時。

- 當希望提高系統的可讀性和可維護性時。

享元模式? Flyweight

旨在通過共享對象來減少內存使用和提高性能。它特別適用于大量相似對象的場景。享元模式的核心思想是將對象的狀態分為兩部分：內部狀態和外部狀態。

內部狀態**：對象可以共享的狀態，通常是不可變的。多個對象可以共享同一個內部狀態。

外部狀態**：對象特有的狀態，通常是可變的。外部狀態在使用對象時傳遞給對象。

Flyweight：享元接口，定義了需要實現的方法。
ConcreteFlyweight：具體享元類，實現了Flyweight接口，包含內部狀態。
FlyweightFactory：享元工廠，負責創建和管理享元對象，確保共享相同的對象。

使用場景:

當應用程序需要大量相似對象時。

當對象的創建和管理成本較高時。

當需要減少內存使用時。

代理模式? Proxy

問題:?需要控制對某個對象的訪問，或者需要在訪問對象時執行一些額外的操作。
解決方案:?創建一個代理類，代表原始對象，并在訪問原始對象之前或之后執行一些操作。代理就像一個中介，控制對真實對象的訪問
主題接口（Subject）：定義了代理和真實對象的共同接口。
真實主題（RealSubject）**：實現了主題接口，定義了代理所代表的真實對象。
代理 Proxy：持有對真實主題的引用，并實現了主題接口，控制對真實主題的訪問。

代理模式通常用于以下幾種情況：

1. **遠程代理**：為一個對象在不同地址空間提供局部代表。

2. **虛擬代理**：根據需要創建開銷較大的對象，延遲對象的創建。

3. **保護代理**：控制對原始對象的訪問，提供不同的訪問權限。

使用場景

-對象創建開銷很大

- **網絡請求**：在網絡請求中，代理可以用于緩存響應，減少網絡延遲。

- **權限控制**：在訪問敏感數據時，代理可以檢查用戶權限。

- **資源管理**：在處理大對象時，代理可以延遲加載，優化性能。

三.行為型模式?Behavioral Patterns

該類模式主要用于對象之間的職責及其提供的服務的分配，它不僅描述對象或類的模式，還描述了他們之間的通信模式，特別是描述一組對等的對象怎樣相互協作以完成其中任一對象都無法單獨完成的任務。

記憶：10種

責命解，迭中備，觀狀策，訪搞定。

責命解：責任鏈、命令、解釋器。

迭中備：迭代器、中介者、備忘錄。

觀狀策：觀察者、狀態、策略。

訪搞定：訪問者搞定一切！

責任鏈模式 Chain of Responsibility?

它允許將請求的發送者和接收者解耦，使多個對象都有機會處理請求。創建一個對象鏈，每個對象依次嘗試處理請求，直到某個對象處理成功為止。

1. **Handler（處理者）**: 定義一個處理請求的接口，并實現鏈中的處理邏輯。
2. **ConcreteHandler（具體處理者）**: 實現Handler接口，處理請求或將請求傳遞給下一個處理者。
3. **Client（客戶端）**: 創建具體處理者并設置鏈的順序，發送請求。

工作原理

1. 客戶端創建多個處理者，并將它們連接成一條鏈。

2. 客戶端發送請求，鏈中的處理者依次檢查是否能夠處理該請求。

3. 如果某個處理者能夠處理請求，則執行相應的處理邏輯；如果不能，則將請求傳遞給鏈中的下一個處理者。

應用場景：審批流程、異常處理、事件處理等。

命令模式 Command?

目的：將請求封裝為對象，使得可以用不同的請求對客戶進行參數化。
核心思想：將“操作”抽象為對象，支持撤銷、重做、日志記錄等功能。

1. **命令接口（Command）**：定義一個執行操作的接口。
2. **具體命令（ConcreteCommand）**：實現命令接口，定義與接收者之間的綁定關系，并調用接收者的相應操作。
3. **接收者（Receiver）**：知道如何實施與執行一個請求相關的操作。
4. **調用者（Invoker）**：負責調用命令對象來執行請求。
5. **客戶端（Client）**：創建具體命令對象并設置接收者。
應用場景：GUI 按鈕操作、任務隊列、事務管理等。

解釋器模式? Interpreter

目的：定義語言的文法規則，并解釋執行語言中的句子。
核心思想：將語言中的每個符號映射為一個類，通過組合這些類來解析和執行語言。
應用場景：正則表達式解析、數學公式計算、編譯器設計等。

1. 抽象表達式（AbstractExpression）：定義一個解釋操作的接口，所有具體表達式都需要實現這個接口。
2. 終結符表達式（TerminalExpression）：實現了抽象表達式接口，表示文法中的基本元素。通常是一些簡單的語法規則。
3. 非終結符表達式（NonTerminalExpression）：同樣實現了抽象表達式接口，表示文法中的復雜結構，由多個終結符和非終結符組合而成。
4. 上下文（Context）：包含了在解釋過程中需要的一些信息，通常是輸入的字符串或其他數據。

工作原理

解釋器模式的核心思想是將一個復雜的表達式分解為多個簡單的表達式，然后通過遞歸的方式來解釋這些表達式。

假設我們需要解析一個簡單的數學表達式，比如加法和減法。我們可以定義以下結構：

- **抽象表達式**：`Expression` 接口，定義 `interpret(Context context)` 方法。

- **終結符表達式**：`NumberExpression` 類，表示數字。

- **非終結符表達式**：`AddExpression` 和 `SubtractExpression` 類，分別表示加法和減法。

具體步驟如下：

1. **定義文法**：首先需要定義要解析的語言的文法規則。

2. **構建表達式樹**：根據文法規則構建一個表達式樹，樹的每個節點都是一個表達式。

3. **解釋表達式**：通過遍歷表達式樹，調用每個節點的解釋方法，最終得到結果。

使用場景（適用于特定的解析和執行需求）

- 需要系統要能應對“”自定義“”內容的解析。

- 需要解析和執行簡單的語言或表達式。

- 需要對復雜的文法進行處理。

- 需要在運行時動態地解釋和執行代碼。