1. 模板方法模式

模板方法模式是框架中最常用的設計模式。其根本的思路是將算法由框架固定，而將算法中具體的操作交給二次開發者實現。例如一個設備初始化的邏輯，框架代碼如下：

TBool CBaseDevice::Init()
{
  if ( DownloadFPGA() != KErrNone )
  {
    LOG(LOG_ERROR,_L(“Download FPGA fail”));
    return EFalse;
  }
  if ( InitKeyPad() != KerrNone )
  {
    LOG(LOG_ERROR,_L(“Initialize keypad fail”));
    return EFalse;
  }
  return ETrue;
}

DownloadFPGA和InitKeyPad都是CBaseDevice定義的虛函數，二次開發者創建一個繼承于CBaseDevice的子類，具體來實現這兩個接口?？蚣芏x了調用的次序和錯誤的處理方式，二次開發者無須關心，也無權決定。

2. 創建型模式

由于框架通常都涉及到各種不同子類對象的創建，創建型模式是經常使用的。例如一個繪圖軟件的框架，有一個基類定義了圖形對象的接口，基于它可以派生出橢圓，矩形，直線各種子類。當用戶繪制一個圖形時，框架就要實例化該子類。這時候可以用工廠方法，原型方法等等。

class CDrawObj
{
  public:
    virtual int DrawObjTypeID()=0;
    virtual Icon GetToolBarIcon()=0;
    virtual void Draw(Rect rect)=0;
    virtual CDrawObj* Clone()=0;
};

3. 消息訂閱模式

消息訂閱模式是最常用的分離數據和界面的方式。界面開發者只需要注冊需要的數據，當數據變化時框架就會將數據“推”到界面。界面開發者可以無須關注數據的來源和內部組織形式。

消息訂閱模式最常見的問題是同步模式下如何處理重入和超時。作為框架設計者，一定要考慮好這個問題。所謂重入，是二次開發者在消息的回調函數中執行訂閱/取消訂閱的操作，這會破壞消息訂閱的機制。所謂超時是指二次開發者的消息回調函數處理時間過長，導致其他消息無法響應。最簡單的辦法是使用異步模式，讓訂閱者和數據發布者在獨立進程/線程中運行。如果不具備此條件，則必須作為框架的重要約定，禁止二次開發者產生此類問題。

4. 裝飾器模式

裝飾器模式賦予了框架在后期增加功能的能力?？蚣芏x裝飾器的抽象基類，而由具體的實現者實現，動態地添加到框架中。

舉一個游戲中的例子，圖形繪制引擎是一個獨立的模塊，比如可以繪制人物的靜止，跑動等圖像。如果策劃決定在游戲中增加一種叫“隱身衣”的道具，要求穿著此道具的玩家在屏幕上顯示的是若有若無的半透明圖像。應該如何設計圖像引擎來適應后期的游戲升級呢？

當隱身衣被裝備后，就向圖像引擎添加一個過濾器。這是個極度簡化的例子，實際的游戲引擎要比這個復雜。裝飾器模式還常見用于數據的前置和后置處理上。