掃描關注一起學嵌入式，一起學習，一起成長
其根本的思路是將算法由框架固定，而將算法中具體的操作交給二次開發者實現。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的子類，具體來實現這兩個接口。框架定義了調用的次序和錯誤的處理方式，二次開發者無須關心，也無權決定。由于框架通常都涉及到各種不同子類對象的創建，創建型模式是經常使用的。例如一個繪圖軟件的框架，有一個基類定義了圖形對象的接口，基于它可以派生出橢圓，矩形，直線各種子類。當用戶繪制一個圖形時，框架就要實例化該子類。這時候可以用工廠方法，原型方法等等。class CDrawObj{ public: virtual int DrawObjTypeID()=0; virtual Icon GetToolBarIcon()=0; virtual void Draw(Rect rect)=0; virtual CDrawObj* Clone()=0;};
消息訂閱模式是最常用的分離數據和界面的方式。界面開發者只需要注冊需要的數據，當數據變化時框架就會將數據“推”到界面。界面開發者可以無須關注數據的來源和內部組織形式。消息訂閱模式最常見的問題是同步模式下如何處理重入和超時。作為框架設計者，一定要考慮好這個問題。所謂重入，是二次開發者在消息的回調函數中執行訂閱/取消訂閱的操作，這會破壞消息訂閱的機制。所謂超時是指二次開發者的消息回調函數處理時間過長，導致其他消息無法響應。最簡單的辦法是使用異步模式，讓訂閱者和數據發布者在獨立進程/線程中運行。如果不具備此條件，則必須作為框架的重要約定，禁止二次開發者產生此類問題。裝飾器模式賦予了框架在后期增加功能的能力。框架定義裝飾器的抽象基類，而由具體的實現者實現，動態地添加到框架中。舉一個游戲中的例子，圖形繪制引擎是一個獨立的模塊，比如可以繪制人物的靜止，跑動等圖像。如果策劃決定在游戲中增加一種叫“隱身衣”的道具，要求穿著此道具的玩家在屏幕上顯示的是若有若無的半透明圖像。應當隱身衣被裝備后，就向圖像引擎添加一個過濾器。這是個極度簡化的例子，實際的游戲引擎要比這個復雜。裝飾器模式還常見用于數據的前置和后置處理上。
