框窗、視圖和文檔及其關係
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),就我個人觀點而然,在一般的應用中,加入文檔模板是沒有必要的。