A Single Public Sector

---

In the previous chapter, you learned (or were reminded) that every C++ class defines a public sector (also known as the public interface of a class). In simplest terms, the public sector is the set of methods defined by a class that are accessible from an object instance. For example, the CCar class depicted in Figure 2-1 contains a public interface containing exactly three methods:

Figure 2-1: A class with a single public interface.

So far we have created classes with a modest public interface, exposing only a handful of methods. Often C++ classes, especially those found in commercial class libraries, can define a huge number of methods in a class's single public interface. From a practical viewpoint, an extensive public sector can be intimidating to the object user, as a very large surface area is covered in a single class. From a design standpoint, a single large public sector can often be broken into logical individual "interfaces" providing a more manageable and scaleable object architecture.

Factoring a Single Public Interface into Discrete Interfaces

Let's examine a familiar class that has a mammoth public interface, and experiment with an alternative interface-based design. The CWnd class of MFC is the base class for all dialogs, graphical user interface (GUI) widgets, frames, and views in the library. This single class consists of over 100 methods the object user may call directly from an object instance. As you examine the full set of methods exposed by CWnd, you may realize that this mass of functions could be partitioned into smaller logical subsets. In fact, here is the online help listing from Microsoft Developer Network (MSDN) showing the various categories (e.g., logical subsets) of CWnd's functionality:

Figure 2-2: A massive public interface, listed by related functionality.

As mentioned, a large public interface can be intimidating to an object user. If you don't believe me, just create an instance of the CWnd class from within an MFC project, and apply the dot operator. The Visual C++ IntelliSense kicks in, displaying a drop-down list that scrolls for a very long time. While it is true that CWnd does contain methods that "belong together" (they are all window-related methods), it should be clear that this one class might be overburdened with a bit too much responsibility. Rather than exposing a single mammoth public interface to the object user, the class could expose a collection of interfaces, each with a well-defined set of semantically related functions.

Imagine that the CWnd class of MFC exposed a collection of interfaces such as IWindowText, IWindowMenu, IWindowInit, IWindowCoordinate, and so forth. Each of these interfaces would express a single set of related functions. Obviously, an interface named IWindowMenu would contain methods that manipulate a menu, IWindowInit may contain a number of creation-related methods, and so forth.

If this were the case (it isn't; the MFC library was not constructed using interface-based techniques), the object user could request access to a specific interface on the CWnd object and gain access to only the subset of functionality needed at that time. This would certainly scale down the burden of the object users, as they are working only with a specific aspect (e.g., behavior) of the class. When the user of the CWnd object desires another aspect supported by the class, he or she may obtain another interface from the object and access that set of related methods.

An Interface Expresses a Specific Behavior

Interface-based programming encourages the reuse of behavior. Once an interface has been designed, other classes could choose to implement it as well. For example, a status bar might like to support the functionality defined in IWindowText, a dialog class might support the IWindowInit interface to provide support for creating and initializing child controls, and so on. This approach can also help the object user, as he or she could begin to logically associate behaviors to classes supporting the same interface. One might say, "Hey, this class supports IWindowCoordinate, therefore I can call this set of methods." As we will see, interfaces inject polymorphic behavior into a system.

Before we get too far along, we need a working definition. For the time being, we will define an interface to be the following:

An interface is a collection of semantically related functions, which describe a single and unique behavior that may be supported by a class.

Note 

By convention, interfaces begin with an "I-" prefix. Stick to this convention, as you will soon see that an interface is an abstract entity that is never directly creatable.

Diagramming Classes with Multiple Interfaces

A standard notation used to diagram a class that supports numerous interfaces is the "lollipop" or "jack" notation. Each interface supported by a class is represented by a separate jack (a.k.a. lollipop), representing a unique behavior the class provides. The rounded rectangle in the diagram represents some implementation of the supported interfaces. Note that the implementation of the interfaces is irrelevant as far as the object user is concerned. All the user of the object is concerned with is which interfaces (a.k.a. behaviors) are supported. Our new mythical interface-based CWnd class is diagrammed in Figure 2-3:

Figure 2-3: Factoring a single interface into discrete interfaces.

COM is an interface-based programming paradigm. Everything in COM revolves around the creation and implementation of interfaces, and you will see diagrams like this all throughout the COM literature. In many ways, an interface feels much like a public interface of a standard C++ class, with two important (and critical) exceptions: Interfaces never provide an implementation and never define state.

---