C++設計者在C++使用的早期并沒有意識到RTTI（運行時類型檢查）的重要性，后來隨作框架結構的類庫出現及其應用越來越廣泛，RTTI就變得越來越重要了。例如下面的這個語句：

　　CWnd *pWnd；

任何人都知道對象pWnd是CWnd類型的指針。但是如果有一個類CView是從CWnd派生來的，對于下面的語句：

　　CWnd* CreateView()
　　{
　　　return new CView;
　　}

對 于使用CreateView()的用戶而然，pWnd = CreateView()，他如何確定pWnd所指向的對象的真正類型呢？因此，必須有一個能夠在運行時刻就能夠確定指針對象類型的方法，比如給每一個類 型的對象均添加一個IsKindOf()之類的方法，通過此方法判斷指針對象的類型。

　　后來，RTTI被加入了C++的規范，成為C++一個內置的特性。

　 　在MFC的設計者們設計MFC的時候，C++規范中并沒有包含RTTI，但是他們很早就意識到這個問題，所以他們以一種獨特的方式在MFC中實現 RTTI，采用這種方式實現的RTTI對于某個對象而言并不是必須的，也就是說，MFC的設計者們并不將RTTI強加于用戶所設計的類型上，而是讓用戶根 據自己的需要選擇是否他所設計的類型需要RTTI。因而這種方式比C++規范中內置的RTTI更靈活。

　　MFC的設計者們在MFC中采用下面的的方法來實現RTTI：

　 　設計一個基類CObject，在CObject中增加RTTI功能，任何一個類型，如果需要具有RTTI功能，就必須直接或間接派生于CObject采 用宏實現RTTI，對于某個直接或間接從CObject派生來的類型而言，該宏可有可無，如果有該宏，它就具有RTTI功能，反之則無。

        考察CObject

　　我們先從CObject開始，下面是它的定義：

　　class AFX_NOVTABLE CObject
　　{
　　　public:
　　　　// Object model (types, destruction, allocation)
　　　　virtual CRuntimeClass* GetRuntimeClass() const;
　　　　virtual ~CObject(); // virtual destructors are necessary
　　
        　　// Diagnostic allocations
　　　　void* PASCAL operator new(size_t nSize);
　　　　void* PASCAL operator new(size_t, void* p);
　　　　void PASCAL operator delete(void* p);
　　　　void PASCAL operator delete(void* p, void* pPlace);
　　　　void PASCAL operator delete(void *p, LPCSTR lpszFileName, int nLine);

　　　　// Disable the copy constructor and assignment by default so you will get
　　　　// compiler errors instead of unexpected behaviour if you pass objects
　　　　// by value or assign objects.

　　　protected:
　　　　CObject();
　　　private:
　　　　CObject(const CObject& objectSrc); // no implementation
    　　　void operator=(const CObject& objectSrc); // no implementation

　　　// Attributes
　　　public:
　　　　BOOL IsSerializable() const;
　　　　BOOL IsKindOf(const CRuntimeClass* pClass) const;
　
    　　　// Overridables
　　　　virtual void Serialize(CArchive& ar);
　　　　// Implementation
　　　public:
　　　　static const AFX_DATA CRuntimeClass classCObject;
　　};

總的來說，CObject定義了整個從其派生的家族的所有成員所具有的兩個基本的能力：

　　運行時的動態類型檢查(RTTI)能力和序列化能力。在早期的C++版本中，沒有規定RTTI，但MFC的作者們早就未撲先知，以這種構架的形式定義并實現RTTI。體現RTTI的是CObject中的兩個成員函數：

　　virtual CRuntimeClass * GetRuntimeClass() const;
　　BOOL IsKindOf(const CRuntimeClass *pClass) const;

其中，前一個函數用來訪問存儲RTTI信息的一個CRuntimeClass類型的結構，后一個函數供在運行時刻進行類型判斷。我們先來看看CRuntimeClass結構的定義,看看它究竟保存了哪些類型信息。

　　struct CRuntimeClass
　　{
　　    // Attributes
    　　LPCSTR m_lpszClassName;
    　　int m_nObjectSize;
    　　UINT m_wSchema; // schema number of the loaded class
    　　CObject* (PASCAL* m_pfnCreateObject)(); // NULL => abstract class
    　　CRuntimeClass* m_pBaseClass;
    　　
            // Operations
　        CObject* CreateObject();
　　    BOOL IsDerivedFrom(const CRuntimeClass* pBaseClass) const;

　　    // Implementation
　　    void Store(CArchive& ar) const;
　　    static CRuntimeClass* PASCAL Load(CArchive& ar, UINT* pwSchemaNum);
　　    // CRuntimeClass objects linked together in simple list
　　    CRuntimeClass* m_pNextClass; // linked list of registered classes
　　};

上 面就是CRuntimeClass的定義，m_lpszClassName保存類的名稱，m_nObjectSize保存類的實例數據所占內存的的大小。 我們重點要關注的是m_pBaseClass成員，它是指向名稱為m_lpszClassName的類的基類的CRuntimeClass的指針，因此， CRuntimeClass就形成了一個繼承鏈表，這個鏈表記錄了某一族類的繼承關系。

　RTTI的實現：

　　實現RTTI的除了上面兩個函數外，還有幾個相關的宏。我們先看看GetRuntimeClass()和IsKindOf()的實現.

　　1．GetRuntimeClass()的實現
　　CRuntimeClass* CObject::GetRuntimeClass() const
　　{
　　　return RUNTIME_CLASS(CObject);
　　}

　　關鍵就在RUNTIME_CLASS這個宏上，RUNTIME_CLASS宏的實現如下：

　　#define RUNTIME_CLASS(class_name) ((CRuntimeClass*)(&class_name::class##class_name))將宏展開，上面的實現就變成：
　　CRuntimeClass* CObject::GetRuntimeClass() const
　　{
　　　return (CRuntimeClass*)(&CObject::classCObject);
　　}

也就是說，它返回CObject類的一個static型的成員classCObject。

　　2．IsKindOf()的實現
　　BOOL CObject::IsKindOf(const CRuntimeClass* pClass) const
　　{
　　　ASSERT(this != NULL);
　　　// it better be in valid memory, at least for CObject size
　　　ASSERT(AfxIsValidAddress(this, sizeof(CObject)));

　　　// simple SI case
　　　CRuntimeClass* pClassThis = GetRuntimeClass();
　　　return pClassThis->IsDerivedFrom(pClass);
　　}

        前兩行我們不管它，關鍵在于最后一行pClassThis->IsDerivedFrom(pClass),歸根結底就是調用 CRuntimeClass的IsDerivedFrom()方法。下面是CRuntimeClass的成員IsDerivedFrom()的實現：
　　BOOL CRuntimeClass::IsDerivedFrom(const CRuntimeClass* pBaseClass) const
　　{
　　　ASSERT(this != NULL);
　　　ASSERT(AfxIsValidAddress(this, sizeof(CRuntimeClass), FALSE));
　　　ASSERT(pBaseClass != NULL);
　　　ASSERT(AfxIsValidAddress(pBaseClass, sizeof(CRuntimeClass), FALSE));

　　　// simple SI case
　　　const CRuntimeClass* pClassThis = this;
　　　while (pClassThis != NULL)
    　　{
    　　　if (pClassThis == pBaseClass) return TRUE;
    　　　pClassThis = pClassThis->m_pBaseClass;
        　}
　　　return FALSE; // walked to the top, no match
　　}

　　關鍵是上面的一段循環代碼：
　　while (pClassThis != NULL)
　　{
　　　if (pClassThis == pBaseClass) return TRUE;
　　　pClassThis = pClassThis->m_pBaseClass;
　　}

        它從繼承鏈表的某一節點this開始，向后搜索比較，確定繼承關系。

        到這里，或許有人要問，這些CRuntimeClass結構是如何產生的呢？這是一個很好的問題，解決了這個問題，就完全清楚了MFC中RTTI的實現。 使用過Visual C++開發程序的人都應該記得DECLARE_DYNAMIC和IMPLEMENT_DYNAMIC這兩個宏，它們分別用來定義相應類的static CRuntimeClass成員和對該成員初始化。

　　DECLARE_DYNAMIC宏的定義：
　　#define DECLARE_DYNAMIC(class_name) \
　　public: \
　　static const AFX_DATA CRuntimeClass class##class_name; \
　　virtual CRuntimeClass* GetRuntimeClass() const; \

　　例如DECLARE_DYNAMIC(CView)展開成為：
　　public:
　　　static const AFX_DATA CRuntimeClass classCView;
　　　virtual CRuntimeClass* GetRuntimeClass() const;

        由此可見，DECLARE_DYNAMIC宏用來在類的定義中定義靜態CRuntimeClass變量和虛擬GetRuntimeClass()函數。可以 推斷，IMPLEMENT_DYNAMIC宏一定是用來初始化該靜態變量和實現GetRuntimeClass()函數，。不錯，正是這樣！

　　IMPLEMENT_DYNAMIC宏的定義：

　　#define IMPLEMENT_DYNAMIC(class_name, base_class_name) \
　            IMPLEMENT_RUNTIMECLASS(class_name, base_class_name, 0xFFFF, NULL)

　　#define IMPLEMENT_RUNTIMECLASS(class_name, base_class_name, wSchema, pfnNew) \
    　　    AFX_COMDAT const AFX_DATADEF CRuntimeClass class_name::class##class_name = { \
　　        #class_name, sizeof(class class_name), wSchema, pfnNew, \
　　        RUNTIME_CLASS(base_class_name), NULL }; \
                CRuntimeClass* class_name::GetRuntimeClass() const \
        　　{ return RUNTIME_CLASS(class_name); } \

        例如IMPLEMENT_DYNAMIC（CView, CWnd）展開如下：
　　file://下面展開的代碼用來初始化靜態CRuntimeClass變量

　　AFX_COMDATA const AFX_DATADEF CRuntimeClass CView::classCView =
　　{
　　　“CView”, file://m_lpszClassName
　　　sizeof(class CView), file://m_nObjectSize
　　　0xffff, file://m_wSchema
　　　NULL, file://m_pfnCreateObject
　　　(CRuntimeClass*)(&CWnd::classCWnd), file://m_pBaseClass
　　　NULL file://m_pNextClass
　　}

　　file://下面的代碼用來實現GetRuntimeClass()函數
　　CRuntimeClass* CView::GetRuntimeClass() const
　　{
                 return (CRuntimeClass*)(&CView::classCView);
        }

        總的來說，同RTTI有關的宏有下面幾對：

　　DECLARE_DYNAMIC和IMPLEMENT_DYNAMIC

        這一對宏能夠提供運行是類型判斷能力。（定義并實現IsKindOf()）

　　DECLARE_DYNCREATE和IMPLEMENT_DYNCREATE

        這一對宏除了能夠提供類型判斷能力外，還能夠提供動態創建對象的能力．(定義并實現IsKindOf()和CreateObject()）

　　DECLARE_SERIAL和IMPLEMENT_SERIAL

這一對宏除了提供類型判斷能力、動態創建對象能力外，還具有序列化功能。（定義并實現IsKindOf()、CreateObject()和Serialize()）

　　框窗、視圖和文檔對象的創建順序和過程

　　前面說過，框窗、視圖和文檔是一個三位一體的框架結構，但實際上，這個三位一體并不是緊耦合的，這個“不是緊耦合“的意思就是，可以將三者分開，可以去掉文檔，而只保留視圖和框窗并且維持兩者的原有關系；也可以去掉視圖和文檔，而只留框窗，程序照樣可以在框架內運作。

　　在MFC中，將三者組織在一起的是文檔模板（Document Template），就我個人觀點而然，在一般的應用中，加入文檔模板是沒有必要的。

MFC編程特點
如 果你曾經使用過傳統的windows編程方法開發應用程序，你會深刻地體會到，即使是開發一個簡單的windows應用程序也需要對windows的編程 原理有很深刻的認識，同時也要手工編寫很多的代碼。因為程序的出錯率幾乎是隨著代碼長度的增加呈幾何級數增長的，這就使得調試程序變得非常困難。所以傳統 的windows編程是需要極大的耐心和豐富的編程經驗的。

　　近幾年來，面向對象技術無論是在理論還是實踐上都在飛速地發展。面向對象 技術中最重要的就是“對象”的概念，它把現實世界中的氣球、自行車等客觀實體抽象成程序中的“對象”。這種“對象”具有一定的屬性和方法，這里的屬性指對 象本身的各種特性參數。如氣球的體積，自行車的長度等，而方法是指對象本身所能執行的功能，如氣球能飛，自行車能滾動等。一個具體的對象可以有許多的屬性 和方法，面向對象技術的重要特點就是對象的封裝性，對于外界而言，并不需要知道對象有哪些屬性，也不需要知道對象本身的方法是如何實現的，而只需要調用對 象所提供的方法來完成特定的功能。從這里我們可以看出，當把面向對象技術應用到程序設計中時，程序員只是在編寫對象方法時才需要關心對象本身的細節問題， 大部分的時間是放在對對象的方法的調用上，組織這些對象進行協同工作。

　　MFC的英文全稱是Microsoft Fundation Classes，即微軟的基本類庫，MFC的本質就是一個包含了許多微軟公司已經定義好的對象的類庫，我們知道，雖然我們要編寫的程序在功能上是千差萬別 的，但從本質上來講，都可以化歸為用戶界面的設計，對文件的操作，多媒體的使用，數據庫的訪問等等一些最主要的方面。這一點正是微軟提供MFC類庫最重要 的原因，在這個類庫中包含了一百多個程序開發過程中最常用到的對象。在進行程序設計的時候，如果類庫中的某個對象能完成所需要的功能，這時我們只要簡單地 調用已有對象的方法就可以了。我們還可以利用面向對象技術中很重要的“繼承”方法從類庫中的已有對象派生出我們自己的對象，這時派生出來的對象除了具有類 庫中的對象的特性和功能之外，還可以由我們自己根據需要加上所需的特性和方法，產生一個更專門的，功能更為強大的對象。當然，你也可以在程序中創建全新的 對象，并根據需要不斷完善對象的功能。

　　正是由于MFC編程方法充分利用了面向對象技術的優點，它使得我們編程時極少需要關心對象方法的實現細節，同時類庫中的各種對象的強大功能足以完成我們程序中的絕大部分所需功能，這使得應用程序中程序員所需要編寫的代碼大為減少，有力地保證了程序的良好的可調試性。

　　最后要指出的是MFC類庫在提供的對象的各種屬性和方法都是經過謹慎的編寫和嚴格的測試，可靠性很高，這就保證了使用MFC類庫不會影響程序的可靠性和正確性。