C++筆記十二（C++設計模式）

本周內容
（1）工廠方法
（2）抽象工廠
（3）原型模式
（4）構建器
（5）門面模式
（6）代理模式
（7）適配器
（8）中介者

“對象創建”模式

  • 通過“對象創建”模式繞開new，來避免對象創建（new）過程中所導致的緊耦合（依賴具體類），從而支持對象創建的穩定。它是接口抽象之后的第一步工作。

  • 典型模式

    • Factory Method
    • Abstract Factory
    • Prototype
    • Builder

一 工廠方法

動機

  • 在軟件系統中，經常面臨著創建對象的工作；由于需求的變化，需要創建的對象的具體類型經常變化。
  • 如何應對這種變化？如何繞過常規的對象創建方法（new），提供一種“封裝機制”來避免客戶程序和這種“具體對象創建工作”的緊耦合？

模式定義:
定義一個用于創建對象的接口，讓子類決定實例化哪一個類。Factory Method使得一個類的實例化延遲（目的：解耦，手段：虛函數）到子類。——《設計模式》GoF

工廠模式改造前：

//MainForm1.cpp
class MainForm : public Form
{
    TextBox* txtFilePath;
    TextBox* txtFileNumber;
    ProgressBar* progressBar;

public:
    void Button1_Click(){


        
        ISplitter * splitter=
            new BinarySplitter();//依賴具體類
        
        splitter->split();

    }
};

//FileSplitter1.cpp
class ISplitter{
public:
    virtual void split()=0;
    virtual ~ISplitter(){}
};

class BinarySplitter : public ISplitter{
};

class TxtSplitter: public ISplitter{
};

class PictureSplitter: public ISplitter{
};

class VideoSplitter: public ISplitter{
};

工廠模式改造后：

//MainForm2.cpp
class MainForm : public Form
{
    SplitterFactory*  factory;//工廠

public:
    
    MainForm(SplitterFactory*  factory){
        this->factory=factory;
    }
    
    void Button1_Click(){

        
        ISplitter * splitter=
            factory->CreateSplitter(); //多態new
        
        splitter->split();

    }
};

//FileSplitter2.cpp
//具體類
class BinarySplitter : public ISplitter{
    
};

class TxtSplitter: public ISplitter{
    
};

class PictureSplitter: public ISplitter{
    
};

class VideoSplitter: public ISplitter{
    
};

//具體工廠
class BinarySplitterFactory: public SplitterFactory{
public:
    virtual ISplitter* CreateSplitter(){
        return new BinarySplitter();
    }
};

class TxtSplitterFactory: public SplitterFactory{
public:
    virtual ISplitter* CreateSplitter(){
        return new TxtSplitter();
    }
};

class PictureSplitterFactory: public SplitterFactory{
public:
    virtual ISplitter* CreateSplitter(){
        return new PictureSplitter();
    }
};

class VideoSplitterFactory: public SplitterFactory{
public:
    virtual ISplitter* CreateSplitter(){
        return new VideoSplitter();
    }
};

//ISplitterFactory.cpp
//抽象類
class ISplitter{
public:
    virtual void split()=0;
    virtual ~ISplitter(){}
};

//工廠基類
class SplitterFactory{
public:
    virtual ISplitter* CreateSplitter()=0;
    virtual ~SplitterFactory(){}
};

工廠結構：


工廠方法.png

要點總結

  • Factory Method模式用于隔離類對象的使用者和具體類型之間的耦合關系。面對一個經常變化的具體類型，緊耦合關系（new）會導致軟件的脆弱。
  • Factory Method模式通過面向對象的手法，將所要創建的具體對象工作延遲到子類，從而實現一種擴展（而非更改）的策略，較好地解決了這種緊耦合關系。
  • Factory Method模式解決“單個對象”的需求變化。缺點在于要求創建方法/參數相同。

二 抽象工廠

動機

  • 在軟件系統中，經常面臨著“一系列相互依賴的對象”的創建工作；同時，由于需求的變化，往往存在更多系列對象的創建工作。
  • 如何應對這種變化？如何繞過常規的對象創建方法（new），提供一種“封裝機制”來避免客戶程序和這種“多系列具體對象創建工作”的緊耦合？

模式定義:
提供一個接口，讓該接口負責創建一系列“相關或者互相依賴的對象”，無需指定它們具體的類。————《設計模式》GoF

EmployeeDAO1：

class EmployeeDAO{  
public:
    vector<EmployeeDO> GetEmployees(){
        SqlConnection* connection =
            new SqlConnection();
        connection->ConnectionString = "...";

        SqlCommand* command =
            new SqlCommand();
        command->CommandText="...";
        command->SetConnection(connection);

        SqlDataReader* reader = command->ExecuteReader();
        while (reader->Read()){
        }
    }
};

EmployeeDAO2：

//數據庫訪問有關的基類
class IDBConnection{
    
};
class IDBConnectionFactory{
public:
    virtual IDBConnection* CreateDBConnection()=0;
};

class IDBCommand{
    
};
class IDBCommandFactory{
public:
    virtual IDBCommand* CreateDBCommand()=0;
};

class IDataReader{
    
};
class IDataReaderFactory{
public:
    virtual IDataReader* CreateDataReader()=0;
};

//支持SQL Server
class SqlConnection: public IDBConnection{
    
};
class SqlConnectionFactory:public IDBConnectionFactory{
    
};

class SqlCommand: public IDBCommand{
    
};
class SqlCommandFactory:public IDBCommandFactory{
    
};

class SqlDataReader: public IDataReader{
    
};
class SqlDataReaderFactory:public IDataReaderFactory{
    
};

//支持Oracle
class OracleConnection: public IDBConnection{
    
};

class OracleCommand: public IDBCommand{
    
};

class OracleDataReader: public IDataReader{
    
};

class EmployeeDAO{
    IDBConnectionFactory* dbConnectionFactory;
    IDBCommandFactory* dbCommandFactory;
    IDataReaderFactory* dataReaderFactory; 
public:
    vector<EmployeeDO> GetEmployees(){
        IDBConnection* connection =
            dbConnectionFactory->CreateDBConnection();
        connection->ConnectionString("...");

        IDBCommand* command =
            dbCommandFactory->CreateDBCommand();
        command->CommandText("...");
        command->SetConnection(connection); //關聯性

        IDBDataReader* reader = command->ExecuteReader(); //關聯性
        while (reader->Read()){

        }
    }
};

EmployeeDAO3：

//數據庫訪問有關的基類
class IDBConnection{
    
};

class IDBCommand{
    
};

class IDataReader{
    
};

class IDBFactory{
public:
    virtual IDBConnection* CreateDBConnection()=0;
    virtual IDBCommand* CreateDBCommand()=0;
    virtual IDataReader* CreateDataReader()=0;
};

//支持SQL Server
class SqlConnection: public IDBConnection{
    
};
class SqlCommand: public IDBCommand{
    
};
class SqlDataReader: public IDataReader{
    
};

class SqlDBFactory:public IDBFactory{
public:
    virtual IDBConnection* CreateDBConnection()=0;
    virtual IDBCommand* CreateDBCommand()=0;
    virtual IDataReader* CreateDataReader()=0;
};

//支持Oracle
class OracleConnection: public IDBConnection{

};

class OracleCommand: public IDBCommand{
    
};

class OracleDataReader: public IDataReader{
    
};

class EmployeeDAO{
    IDBFactory* dbFactory;
    
public:
    vector<EmployeeDO> GetEmployees(){
        IDBConnection* connection =
            dbFactory->CreateDBConnection();
        connection->ConnectionString("...");

        IDBCommand* command =
            dbFactory->CreateDBCommand();
        command->CommandText("...");
        command->SetConnection(connection); //關聯性

        IDBDataReader* reader = command->ExecuteReader(); //關聯性
        while (reader->Read()){

        }
    }
};

抽象工廠結構：


抽象工廠結構.png

要點總結：

  • 如果沒有應對“多系列對象構建”的需求變化，則沒有必要使用Abstract Factory模式，這時候使用簡單的工廠完全可以。
  • “系列對象”指的是在某一特定系列下的對象之間有相互依賴、或作用的關系。不同系列的對象之間不能相互依賴。
  • Abstract Factory模式主要在于應對“新系列”的需求變動。其缺點在于難以應對“新對象”的需求變動。

三 Prototype原型模式

動機

  • 在軟件系統中，經常面臨著“某些結構復雜的對象”的創建工作；由于需求的變化，這些對象經常面臨著劇烈的變化，但是它們卻擁有比較穩定一致的接口。
  • 如何應對這種變化？如何向“客戶程序（使用這些對象的程序）”隔離出“這些易變對象”，從而使得“依賴這些易變對象的客戶程序”不隨著需求改變而改變？

模式定義：
使用原型實例指定創建對象的種類，然后通過拷貝這些原型來創建新的對象。——《設計模式》GoF

原型模式結構：


原型模式.png

要點總結：

  • Prototype模式同樣用于隔離類對象的使用者和具體類型（易變類）之間的耦合關系，它同樣要求這些“易變類”擁有“穩定的接口”。
  • Prototype模式對于“如何創建易變類的實體對象”采用“原型克隆”的方法來做，它使得我們可以非常靈活地動態創建“擁有某些穩定接口”的新對象——所需工作僅僅是注冊一個新類的對象（即原型），然后在任何需要的地方Clone。
  • Prototype模式中的Clone方法可以利用某些框架中的序列化來實現深拷貝。

四 Builder構建器

動機

  • 在軟件系統中，有時候面臨著“一個復雜對象”的創建工作，其通常由各個部分的子對象用一定的算法構成；由于需求的變化，這個復雜對象的各個部分經常面臨著劇烈的變化，但是將它們組合在一起的算法卻相對穩定。
  • 如何應對這種變化？如何提供一種“封裝機制”來隔離出“復雜對象的各個部分”的變化，從而保持系統中的“穩定構建算法”不隨著需求改變而改變？

模式定義：
將一個復雜對象的構建與其表示相分離，使得同樣的構建過程（穩定）可以創建不同的表示（變化）。————《設計模式》GoF

構建器結構：


構建器.png

要點總結：

  • Builder模式主要用于“分步驟構建一個復雜的對象”。在這其中“分步驟”是一個穩定的算法，而復雜對象的各個部分則經常變化。
  • 變化點在哪里，封裝哪里——Builder模式主要在于應對“復雜對象各個部分”的頻繁需求變動。其缺點在于難以應對“分步驟構建算法”的需求變動。
  • 在Builder模式中，要注意不同語言中構造器內調用虛函數的差別（C++ vs. C#）。

“接口隔離”模式

  • 在組件構建過程中，某些接口之間直接的依賴常常會帶來很多問題，甚至根本無法實現。采用添加一層間接（穩定）接口，來隔離本來互相緊密關聯的接口是一種常見的解決方案。
  • 典型模式
    • Facade
    • Proxy
    • Adapter
    • Mediator

五 Facade門面模式

動機

  • 上述A方案的問題在于組件的客戶和組件中各種復雜的子系統有了過多的耦合，隨著外部客戶程序和各子系統的演化，這種過多的耦合面臨很多變化的挑戰。
  • 如何簡化外部客戶程序和系統間的交互接口？如何將外部客戶程序的演化和內部子系統的變化之間的依賴相互解耦？

模式定義：
為子系統中的一組接口提供一個一致（穩定）的界面Facade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用（復用）。————《設計模式》GoF

門面模式結構：


門面模式結構.png

要點總結：

  • 從客戶程序的角度來看，Facade模式簡化了整個組件系統的接口，對于組件內部與外部客戶程序來說，達到了一種“解耦”的效果——內部子系統的任何變化不會影響到Facade接口的變化。
  • Facade設計模式更注重從架構的層次去看整個系統，而不是單個類的層次。Facade很多時候更是一種架構設計模式。
  • Facade設計模式并非一個集裝箱，可以任意地放進任何多個對象。Facade模式中組件的內部應該是“相互耦合關系比較大的一系列組件”，而不是一個簡單的功能集合。

六 Proxy代理模式

動機

  • 在面向對象系統中，有些對象由于某種原因（比如對象創建的開銷很大，或者某些操作需要安全控制，或者需要進程外的訪問等），直接訪問會給使用者、或者系統結構帶來很多麻煩。
  • 如何在不失去透明操作對象的同時來管理/控制這些對象特有的復雜性？增加一層間接層是軟件開發中常見的解決方式。

模式定義：
為其他對象提供一種代理以控制（隔離，使用接口）對這個對象的訪問。————《設計模式》GoF

要點總結：

  • “增加一層間接層”是軟件系統中對許多復雜問題的一種常見解決方法。在面向對象系統中，直接使用某些對象會帶來很多問題，作為間接層的proxy對象便是解決這一問題的常見手段。
  • 具體proxy設計模式的實現方式、實現粒度都相差很大，有些可能對單個對象做細粒度的控制，如copy-on-write技術，有些可能對組件模塊提供抽象代理層，在架構層次對對象做proxy。
  • Proxy并不一定要求保持接口完整的一致性，只要能夠實現間接控制，有時候損及一些透明性是可以接受的。

七 Adapter適配器

動機

  • 在軟件系統中，由于應用環境的變化，常常需要將“一些現存的對象”放在新的環境中應用，但是新環境要求的接口是這些現存對象所不滿足的。
  • 如何應對這種“遷徙的變化”？如何既能利用現有對象的良好實現，同時又能滿足新的應用環境所要求的接口？

模式定義：
將一個類的接口轉換成客戶希望的另一個接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。————《設計模式》GoF

要點總結：

  • Adapter模式主要應用于“希望復用一些現存的類，但是接口又與復用環境要求不一致的情況”，在遺留代碼復用、類庫遷徙等方面非常有用。
  • GoF 23定義了兩種Adapter模式的實現結構：對象適配器和類適配器。但類適配器采用“多繼承”的實現方式，一般不推薦使用。對象適配器采用“對象組合”的方式，更符合松耦合精神。
  • Adapter模式可以實現的非常靈活，不必拘泥于Gof23中定義的兩種結構。例如，完全可以將Adapter模式中的“現存對象”作為新的接口方法參數，來達到適配的目的。

八 Mediator中介者

動機

  • 在軟件構建過程中，經常會出現多個對象互相關聯交互的情況，對象之間常常會維持一種復雜的引用關系，如果遇到一些需求的更改，這種直接的引用關系將面臨不斷的變化。
  • 在這種情況下，我們可使用一個“中介對象”來管理對象間的關聯關系，避免相互交互的對象之間的緊耦合引用關系，從而更好地抵御變化。

模式定義：
用一個中介對象來封裝（封裝變化）一系列的對象交互。中介者使各對象不需要顯式的相互引用（編譯時依賴->運行時依賴），從而使其耦合松散（管理變化），而且可以獨立地改變它們之間的交互。————《設計模式》GoF

中介者結構：


中介者結構.png

要點總結：

  • 將多個對象間復雜的關聯關系解耦，Mediator模式將多個對象間的控制邏輯進行集中管理，變“多個對象互相關聯”為“多個對象和一個中介者關聯”，簡化了系統的維護，抵御了可能的變化。
  • 隨著控制邏輯的復雜化，Mediator具體對象的實現可能想當復雜。這時候可以對Mediator對象進行分解處理。
  • Facade模式是解耦系統間（單向）的對象關聯關系；Mediator模式是解耦系統內各個對象之間（雙向）的關聯關系。
最后編輯于 ：
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發布，文章內容僅代表作者本人觀點，簡書系信息發布平臺，僅提供信息存儲服務。

推薦閱讀更多精彩內容

  • “對象創建”模式 通過“對象創建”模式繞開new，來避免對象創建（new）過程中所導致的緊耦合（依賴具體類），從而...
    一般的路人丙閱讀 1,176評論 0贊 1
  • 上周講述了DOF設計模式中的“組件協作”模式（包括template method模式、strategy策略模式、o...
    cayhw閱讀 266評論 0贊 0
  • 對象創建模式： 通過“對象創建”模式繞開new，來避免對象創建（new）過程中所導致的緊耦合（依賴具體類），從而支...
    hjsadam閱讀 261評論 0贊 0
  • 設計模式匯總 一、基礎知識 1. 設計模式概述 定義：設計模式（Design Pattern）是一套被反復使用、多...
    MinoyJet閱讀 3,970評論 1贊 15
  • 設計模式基本原則 開放-封閉原則（OCP），是說軟件實體（類、模塊、函數等等）應該可以拓展，但是不可修改。開-閉原...
    西山薄涼閱讀 3,869評論 3贊 14