進入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
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），就我個人觀點而然，在一般的應用中，加入文檔模板是沒有必要的。