進入MFC講壇的前言(五)

框窗、視圖和文檔及其關系 

　　MFC架構的另外一個特色是它的框窗、視圖和文檔這個三位一體的結構，它是一個典型的MVC（Model、View and Controler）結構。嚴格的講，框窗不屬于MVC中的任何一項，MFC設計者将框窗加進來是為了能更好的協調文檔 和視圖。而MVC中的Controler這一項，則是應用本身的應用邏輯。 在這三者中，需要特别注意的、也最能夠展現個人的程式設計水準的是框窗。一旦三者都存在于記憶體中，它們的關系就變得很簡單。本章将讨論下述内容：

　　1．MFC的RTTI（Run Time Type Inspection，運作時類型檢查）

　　　框窗、視圖和文檔的建立順序和過程。

　　　框窗、視圖和文檔的删除順序和過程。

　　　框窗、視圖和文檔之間的互相通路接口。

　　　框窗、視圖和文檔對菜單和工具條消息處理的先後順序

　　MFC的RTTI

　　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

　　　　BOOL IsSerializable() const;

　　　　BOOL IsKindOf(const CRuntimeClass* pClass) const;

　　　　// Overridables

　　　　virtual void Serialize(CArchive& ar);

　　　　// Implementation

　　　　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))将宏展開，上面的實作就變成：

　　　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(AfxIsValidAddress(this, sizeof(CRuntimeClass), FALSE));

　　　ASSERT(pBaseClass != NULL);

　　　ASSERT(AfxIsValidAddress(pBaseClass, sizeof(CRuntimeClass), FALSE));

　　　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)

它從繼承連結清單的某一節點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），就我個人觀點而然，在一般的應用中，加入文檔模闆是沒有必要的。