This main topic of this article is to show how patterns are used in MFC. We will be seeing the usage of three patterns in MFC library.
Creational : Singleton Pattern
First step in any MFC application is the creation of application object (object of class derived from CWinApp). There should be only one application object in an instance of MFC application. CWinApp is designed to make sure that only application object is present in a given instance. CWinApp and its descendants are called Singleton Classes. A class (CWinApp or its descendant) that assures a maximum of ONE object of its type at a given time and provides a global access point (AfxGetApp() method) to this object is a Singleton class.
As this principle is applied over and over again to solve recurring object "creational" problems, this becomes a pattern. Singleton Pattern ensures that a class only has one instance and provides a global access point it. The article Creating Singleton Objects using Visual C++ talks about different approaches for implementing Singletons.
Structural : Bridge Pattern
Bridge Pattern is all about decoupling an abstraction (interface) from its implementation so that the two can vary independently. In MFC, the process of storing/retrieving an object to/from a persistence mechanism (like a file) is called Serialization. MFC uses the Bridge Pattern to implement Serialization. CArchive and CFile classes implement object Serialization. CArchive class provides the interface for writing/reading an object to/from a persistence mechanism whereas the CFile and its sub classes provides implementation for different persistence mechanisms such as memory, disk file, sockets etc.
A CArchive object is configured with an object of class CFile (or a derived class) during its construction, from which it obtains the necessary information for serialization, including the filename and type of the requested operation (a read or write). Client performing the Serialization operation can use CArchive object without regarding the persistence mechanism implemented by CFile classes.
The article Bridge Pattern - Bridging the gap between Interface and Implementation talks about Bridge pattern in detail.
Behavioral : Observer Pattern
The Observer Pattern is intended to "Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically". An object that is subjected to change is called a Subject and an object that depends on the Subject's state is called an Observer.
MFC uses a Document/View variant of the Observer Pattern. MFC's famous Document/View architecture uses this variant. A document contains the data object and acts as a Subject. A view is a window object through which the user updates the document and it acts as an Observer. A document can have multiple views. Whenever the data in the document is changed by one of the views, it updates the document by calling UpdateAllViews method, with optional hint about the modification. To inform about the change to other views, the document object calls OnUpdate method for each view attached to it (except the view that called UpdateAllViews). Derived view classes can override the OnUpdate method and update themselves by querying the data from the document.
The article Applying Observer Pattern in C++ Applications talks about Observer pattern in detail.
Summary
Design Pattern provides a common language for designers and helps them to decompose systems into a set of cooperating classes and objects. They provide proven design solution to recurring problems. In this article, I have introduced the design pattern and how MFC is using some of the patterns in its design. We can easily find more and more patterns when we dig into MFC and its classes.