Why does MFC not provide encapsulation?

Question

Hi,

I have always wondered why MFC classes present most of their data members publicly and not "hidden" in the private sector and accessed/modified by get/set methods. And it is THE reigning architecture!!  So, why abandon Object Oriented Principles in MFC?

Regards,

Juan Dent

---

Juan Dent

Answer 1

Hello,

I looked at CWnd and CString. The member variables are ok, mostly protected or private, with Get/Set-functions. I don't see why MS abandon OOP.

Which classes do you mean?

Regards, Guido

Answer 2

I think you must remember how old MFC is. The first version was released in 1992 and this was before C++ was first standardised in C++98.

While the MFC has had incremental updates since then, it hasn't had a decent overhaul. You can see that in a few places in the MFC code base. So while these days things have matured a lot, 25 years ago things were different.

---

This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

Answer 3

Hi Guido!

Just take a look at CWinApp for an example of a VERY unencapsulated class (and most others in MFC are like that).

class CWinApp : public CWinThread
{
	DECLARE_DYNAMIC(CWinApp)
public:

// Constructor
	explicit CWinApp(LPCTSTR lpszAppName = NULL);     // app name defaults to EXE name

// Attributes
	// Startup args (do not change)

	// This module's hInstance.
	HINSTANCE m_hInstance;

	// Pointer to the command-line.
	LPTSTR m_lpCmdLine;

	// Initial state of the application's window; normally,
	// this is an argument to ShowWindow().
	int m_nCmdShow;

	// Running args (can be changed in InitInstance)

	// Human-redable name of the application. Normally set in
	// constructor or retreived from AFX_IDS_APP_TITLE.
	LPCTSTR m_pszAppName;

	/// <summary>
	/// Application User Model ID.</summary>
	LPCTSTR m_pszAppID;

	// Name of registry key for this application. See
	// SetRegistryKey() member function.
	LPCTSTR m_pszRegistryKey;

	// Pointer to CDocManager used to manage document templates
	// for this application instance.
	CDocManager* m_pDocManager;

	// Support for Shift+F1 help mode.

	// TRUE if we're in SHIFT+F1 mode.
	BOOL m_bHelpMode;

See the problem?

However, we have an answer by Darran Rowe (see below) -- it's just very old architecture!

Regards,

Juan

---

Juan Dent

Answer 4

Can you imagine the extent of the code breakage that would occur if MFC classes were re-written to remove access to class members that have historically been public? 

Answer 5

Indeed!! So we must learn to live with it...

Thanks RLWA32!

Juan

---

Juan Dent