I was talking about re-factoring yesterday, and the approach I was开发者_开发技巧 going for was obviously wrong. I looked into suggested patterns, but the problem was still that the common functionality is really a thing of a supper class, which I couldn't derive from as the MFC puts on it's own requirements for different windows (CWnd/CDialogEx).
Today I got an idea, that is, I could use a superclass template to pack the common logic which would solve the problem, theoretically...
That is, I define templated CCommon class, and inherit it with required superclass in all window classes. Like class CMyWnd : private CCommon<CWnd>
Unfortunately MFC makes things super ugly because of the macros...
#pragma once
template <class T> class CCommon : public T
{
//DECLARE_DYNAMIC(CCommon)
public:
CCommon();
virtual ~CCommon();
//protected:
//DECLARE_MESSAGE_MAP()
};
//IMPLEMENT_DYNAMIC(template <class T> CCommon<T>, CWnd)
template <class T> CCommon<T>::CCommon()
{
}
template <class T> CCommon<T>::~CCommon()
{
}
//BEGIN_MESSAGE_MAP(template <class T> CCommon<T>, CWnd)
//END_MESSAGE_MAP()
Is there a way I could work around this problem?
Things like IMPLEMENT_DYNAMIC(template <class T> CCommonWndLogic<T>, T)
or template <class T> IMPLEMENT_DYNAMIC(CCommonWndLogic<T>, T)
doesn't seem to compile at all. Same with message maps, which I would really like carry over to the base class.
You are asking for trouble with this approach unfortunately. MFC is riddled with hacks and legacy workarounds. Your approach isn't really practical unless you can work with MFC at source level. You really can't. Use MFC strictly as an API to be called as required. Do all your state of the art bleeding edge C++ software engineering in your own independent class hierarcy, and just call MFC as required to implement the details of your UI.
精彩评论