偷Microsoft師學MFC藝：且看C++如何支持反射

原文：http://blog.csdn.net/yah99_wolf/article/details/4039493

若是你問一個IT人士「C++如何實現相似Java的反射？」，結果會怎樣呢？~！@＃￥%……&*，估計大部分人都會要稍微思考了一下，或者直接說「C++根本就不支持反射的呀！」。

是的，C++語言自己是不支持反射的，但實際應用中老是會有將對象序列化的需求，總不可能C++不支持，咱們就不用C++了，既然發明C++的大師們沒有考慮這個，那咱們只有本身動手了，毛主席說過「本身動手，豐衣足食」！

天生限制

C++語言自己不支持反射機制，但C++對象老是要序列化的，序列化就是存儲到磁盤上，將對象變成必定格式的二進制編碼，而後要用的時候再將保存在磁盤上的二進制編碼轉化成一個內存中的對象，這個過程當中老是須要有一個指示來告訴編譯器要生成什麼樣的對象，最簡單的方式固然就是類名了，例如：將一個ClassXXX對象存儲到磁盤上，再從磁盤讀取的時候讓編譯器根據「ClassXXX」名稱來new一個對象。

可是問題出現了，C++語言自己不支持反射，也就是說不能經過以下方式生成一個對象：

ClassXXX object = new 「ClassXXX」；

 

工廠方法

固然，這樣的方法不行，那咱們只有另闢蹊徑。最簡單的就是工廠方法了：

ClassXXX* object = FactoryCreate（「ClassXXX」）；

至於FactoryCreate的設計就很簡單了，if的集合就能夠了：

if(name = 「ClassXXX」)

return new ClassXXX;

if(name = 「ClassYYY」)

return new ClassYYY;

 

看起來不錯，來個類名就能夠生成對應的對象，功能上解決了根據類名生成對象的問題。

假如以上全部的代碼都有你一我的編寫，那固然問題不大，可是假若有一天你的公司擴大了，這部分代碼由兩個不一樣的組A和B來維護，啊哈，問題來了，A組每添加或者修改一個類，都要通知B組更新FactoryCreate函數，也就是說A組的任何關於類的修改，都須要B組來修改，但實際上B的修改不產生任何價值，並且不勝其煩，永無止盡！！若是哪天來了一個新員工，因爲對這個規定還不清楚，忘記了通知，那就完了：編譯通不過！

一個公司內都會產生如此多的問題，更況且微軟這樣的大公司是面對全球的各類各樣的客戶，若是微軟把這部分作進框架代碼中，呵呵，那微軟全部的人不用幹其餘事情了，天天處理來自全球的要求修改FactoryCreate函數的郵件和電話就夠他們忙的了：）

 

回調工廠

既然此路很差走，那麼咱們再考慮其它方法吧，一個可選的方法是將FactoryCreate作成回調函數，框架提供註冊接口RegisterFactoryCreate，框架函數如此實現：

typedef CObject* （*FactoryCreate_PTR）(String name);

RegisterFactoryCreate(FactoryCreate_PTR fc_ptr);

應用代碼如此實現：

CObject* MyFactoryCreate（String name）;

RegisterFactoryCreate(MyFactoryCreate);

到這裏一個框架和應用分離的反射機制基本實現了，你是否長吁一口氣，而後準備泡杯咖啡，稍微放鬆一下呢？確實能夠稍微休息一下了，畢竟咱們完成了一件很是了不得的事情，讓C++實現了反射。

 

但你只清閒了一兩天，麻煩事就來了。員工張三跑來向你抱怨「老大，李四註冊的反射函數把個人覆蓋了」！哦，你仔細一看，My god，這個註冊函數只能註冊一個反射函數，後註冊的就把前面的覆蓋了！

怎麼辦？總不可能又要求全部的類的反射函數都在一個工廠裏實現吧，那這樣就又回到了工廠方法中描述的時代了。

固然，聰明的你估計很快就能想出問題的解決方法，將RegisterFactoryCreate函數稍加修改就能知足要求了，新的實現以下：

RegisterFactoryCreate（FactoryCreate_PTR fc_ptr，String className）

而後要求每一個類都單獨寫本身的FactoryCreate_PTR函數，相似以下方式：

static CObject* ClassXXX::CreateClassXXX (){

       return new ClassXXX;

};

 

static CObject* ClassYYY::CreateClassYYY(){

       return new ClassYYY;

};

 

到此爲此終於大功告成，經過咱們的智慧實現了C++的反射功能！一股自豪感油然升起：）

 

最後的殺手鐗：宏

當你爲本身的聰明才智而驕傲的時候，那邊卻有幾個開發的兄弟在發出抱怨「唉，這麼多類似的函數，看着都眼花，每一個類都要寫，煩死了」。

或者有一天，你要在每一個類的CreateClass函數中增長一個其它功能（例如日誌），那麼開發的兄弟真的是要煩「死了」！！！

 

其實仔細一看，包括函數申明、函數定義、函數註冊，每一個類的代碼除了類名外其它都是如出一轍的，有沒有簡單的方法呢？

確定是有的，這個方法就是宏了，按照以下方法定義宏：

#define DECLARE_CLASS_CREATE(class_name) /

static CObject* CreateClass## class_name ();

 

#define IMPL_CLASS_CREATE(class_name) /

static CObject* CreateClass## class_name (){  /

       return new class_name;             /

};

 

#define REG_CLASS_CREATE(class_name) /

RegisterFactoryCreate(class_name::CreateClass## class_name, #class_name);

注：##是鏈接符，將兩個字符串鏈接起來，#是將class_name做爲字符串處理。

 

你們能夠比較一下，用了宏和不用宏是否是代碼感受徹底不同呢？並且那天須要增長一個簡單的功能，只須要改宏定義就ok了，不要全文搜索全部相關函數，而後一個一個的重複添加。

 

到這裏才真正是大功告成！！

 

後記

某天分析Spring的IOC時，看到Digester最後利用的其實是Java的反射機制來根據XML文件定義生成Java對象，突發奇想：若是是C++該怎麼辦？

因而本身就開始分析起來，分析了一段時間忽然想起微軟的MFC不正是要支持C++對象序列化的嗎？

趕忙打開深刻淺出MFC，從新將這部分研究了一下。看到微軟的天才們在MFC中用宏來實現RTTI、Dynamic Create、Seralize功能時，我反過來思考「若是是我，我會如何設計？」、「爲何會這麼設計」？而後一一分析這些各類可能的實現方式，一步一步的推導，最後發現居然天然而然的就推出了MFC的這種實現方式！

固然，MFC的實現代碼和我給出的代碼不同（註冊方式不同），但設計思想是同樣的，各位看官能夠自行稍加分析就明白了。

MFC的詳細實現能夠參考侯捷的《深刻淺出MFC》。