簡略懂得設計形式中的裝潢者形式及C++版代碼完成

簡略懂得設計形式中的裝潢者形式及C++版代碼完成。本站提示廣大學習愛好者：（簡略懂得設計形式中的裝潢者形式及C++版代碼完成）文章只能為提供參考，不一定能成為您想要的結果。以下是簡略懂得設計形式中的裝潢者形式及C++版代碼完成正文

由碰到的成績引出的裝潢形式

在 OO 設計和開辟進程，能夠會常常碰到以下的情形：我們須要為一個曾經界說好的類添加新的職責（操作），平日的情形我們會給界說一個新類繼續自界說好的類，如許會帶來一個成績（將在本形式的評論辯論中給出）。經由過程繼續的方法處理如許的情形還帶來了體系的龐雜性，由於繼續的深度會變得很深。

而裝潢供給了一種給類增長職責的辦法，不是經由過程繼續完成的，而是經由過程組合。

有關這些內容在評論辯論中進一步論述。
形式選擇
裝潢形式典范的構造圖為：

在 結 構 圖 中 ， ConcreteComponent 和裝潢需 要 有 同 樣 的 接 口 ， 因 此ConcreteComponent 和裝潢有著一個配合的父類。這裡有人會問，讓裝潢直接保護一個指向 ConcreteComponent 援用（指針）不便可以到達異樣的後果，謎底是確定而且能否定的。確定的是你可以經由過程這類方法完成，否認的是你不要用這類方法完成，由於經由過程這類方法你就只能為這個特定的 ConcreteComponent 供給潤飾操作了，當有了一個新的ConcreteComponent 你 又 要 去 新 建 一 個裝潢來 實 現 。 但 是 通 過 結 構 圖 中 的ConcreteComponent 和裝潢有一個公共基類，便可以應用 OO 中多態的思惟來完成只需是 Component 型其余對象都可以供給潤飾操作的類，這類情形下你就算新建了 100 個Component 型其余類 ConcreteComponent，也都可以由裝潢一個類弄定。這也恰是裝潢形式的症結和威力地點了。

固然假如你只用給 Component 型別類添加一種潤飾，則裝潢這個基類就不是很需要了。

實例

#include <iostream> 
using namespace std; 
 
class TestA 
{ 
public: 
  void display_a() 
  { 
    cout<<"display a..."<<endl; 
  } 
}; 
 
class TestB 
{ 
public: 
  void display_b() 
  { 
    cout<<"display b..."<<endl; 
  } 
}; 
 
class Facade 
{ 
  TestA *testa; 
  TestB *testb; 
 
public: 
  Facade() 
  { 
    testa = new TestA(); 
    testb = new TestB(); 
  } 
  ~Facade() 
  { 
    delete testa; 
    delete testb; 
  } 
 
  void MethodA() 
  { 
    testa->display_a(); 
    testb->display_b(); 
  } 
}; 
 
int main() 
{ 
  Facade *facade = new Facade(); 
   
  facade->MethodA(); 
 
  system("pause"); 
  return 0; 
}