ptg7544714 retested, redocumented, or recompiled. From an encapsulation point
of view, there are really only two access levels: private (which offers encapsulation) and everything else (which doesn’t).
Things to Remember
✦Declare data members private. It gives clients syntactically uniform access to data, affords fine-grained access control, allows invariants to be enforced, and offers class authors implementation flexibility.
✦protected is no more encapsulated than public.
Item 23: Prefer non-member non-friend functions to
ptg7544714 So which is better, the member function clearEverything or the non-
member function clearBrowser?
Object-oriented principles dictate that data and the functions that operate on them should be bundled together, and that suggests that the member function is the better choice. Unfortunately, this sugges- tion is incorrect. It’s based on a misunderstanding of what being object-oriented means. Object-oriented principles dictate that data should be as encapsulated as possible. Counterintuitively, the mem- ber function clearEverything actually yields less encapsulation than the non-member clearBrowser. Furthermore, offering the non-member function allows for greater packaging flexibility for WebBrowser-related functionality, and that, in turn, yields fewer compilation dependencies and an increase in WebBrowser extensibility. The non-member approach is thus better than a member function in many ways. It’s important to understand why.
We’ll begin with encapsulation. If something is encapsulated, it’s hid- den from view. The more something is encapsulated, the fewer things can see it. The fewer things can see it, the greater flexibility we have to change it, because our changes directly affect only those things that can see what we change. The greater something is encapsulated, then, the greater our ability to change it. That’s the reason we value encap- sulation in the first place: it affords us the flexibility to change things in a way that affects only a limited number of clients.
Consider the data associated with an object. The less code that can see the data (i.e., access it), the more the data is encapsulated, and the more freely we can change characteristics of an object’s data, such as the number of data members, their types, etc. As a coarse-grained measure of how much code can see a piece of data, we can count the number of functions that can access that data: the more functions that can access it, the less encapsulated the data.
Item 22 explains that data members should be private, because if they’re not, an unlimited number of functions can access them. They have no encapsulation at all. For data members that are private, the number of functions that can access them is the number of member functions of the class plus the number of friend functions, because only members and friends have access to private members. Given a choice between a member function (which can access not only the pri- vate data of a class, but also private functions, enums, typedefs, etc.) and a non-member non-friend function (which can access none of these things) providing the same functionality, the choice yielding greater encapsulation is the non-member non-friend function, because it doesn’t increase the number of functions that can access
ptg7544714 the private parts of the class. This explains why clearBrowser (the non-
member non-friend function) is preferable to clearEverything (the mem- ber function): it yields greater encapsulation in the WebBrowser class.
At this point, two things are worth noting. First, this reasoning applies only to non-member non-friend functions. Friends have the same access to a class’s private members that member functions have, hence the same impact on encapsulation. From an encapsulation point of view, the choice isn’t between member and non-member func- tions, it’s between member functions and non-member non-friend functions. (Encapsulation isn’t the only point of view, of course.
Item 24 explains that when it comes to implicit type conversions, the choice is between member and non-member functions.)
The second thing to note is that just because concerns about encap- sulation dictate that a function be a non-member of one class doesn’t mean it can’t be a member of another class. This may prove a mild salve to programmers accustomed to languages where all functions must be in classes (e.g., Eiffel, Java, C#, etc.). For example, we could make clearBrowser a static member function of some utility class. As long as it’s not part of (or a friend of) WebBrowser, it doesn’t affect the encapsulation of WebBrowser’s private members.
In C++, a more natural approach would be to make clearBrowser a non- member function in the same namespace as WebBrowser:
namespace WebBrowserStuff { class WebBrowser { ... };
void clearBrowser(WebBrowser& wb);
...
}
This has more going for it than naturalness, however, because namespaces, unlike classes, can be spread across multiple source files. That’s important, because functions like clearBrowser are conve- nience functions. Being neither members nor friends, they have no special access to WebBrowser, so they can’t offer any functionality a WebBrowser client couldn’t already get in some other way. For exam- ple, if clearBrowser didn’t exist, clients could just call clearCache, clear- History, and removeCookies themselves.
A class like WebBrowser might have a large number of convenience functions, some related to bookmarks, others related to printing, still others related to cookie management, etc. As a general rule, most cli- ents will be interested in only some of these sets of convenience func- tions. There’s no reason for a client interested only in bookmark-
ptg7544714 related convenience functions to be compilation dependent on, e.g.,
cookie-related convenience functions. The straightforward way to sep- arate them is to declare bookmark-related convenience functions in one header file, cookie-related convenience functions in a different header file, printing-related convenience functions in a third, etc.:
// header “webbrowser.h” — header for class WebBrowser itself // as well as “core” WebBrowser-related functionality
namespace WebBrowserStuff { class WebBrowser { ... };
... // “core” related functionality, e.g.
// non-member functions almost // all clients need
}
// header “webbrowserbookmarks.h”
namespace WebBrowserStuff {
... // bookmark-related convenience
} // functions
// header “webbrowsercookies.h”
namespace WebBrowserStuff {
... // cookie-related convenience
} // functions
...
Note that this is exactly how the standard C++ library is organized.
Rather than having a single monolithic <C++StandardLibrary> header containing everything in the std namespace, there are dozens of head- ers (e.g., <vector>, <algorithm>, <memory>, etc.), each declaring some of the functionality in std. Clients who use only vector-related func- tionality aren’t required to #include <memory>; clients who don’t use list don’t have to #include <list>. This allows clients to be compilation dependent only on the parts of the system they actually use. (See Item 31 for a discussion of other ways to reduce compilation depen- dencies.) Partitioning functionality in this way is not possible when it comes from a class’s member functions, because a class must be defined in its entirety; it can’t be split into pieces.
Putting all convenience functions in multiple header files — but one namespace — also means that clients can easily extend the set of con- venience functions. All they have to do is add more non-member non- friend functions to the namespace. For example, if a WebBrowser client decides to write convenience functions related to downloading images, he or she just needs to create a new header file containing the decla- rations of those functions in the WebBrowserStuff namespace. The new functions are now as available and as integrated as all other conve-
ptg7544714 nience functions. This is another feature classes can’t offer, because
class definitions are closed to extension by clients. Sure, clients can derive new classes, but derived classes have no access to encapsu- lated (i.e., private) members in the base class, so such “extended func- tionality” has second-class status. Besides, as Item 7 explains, not all classes are designed to be base classes.
Things to Remember
✦Prefer non-member non-friend functions to member functions. Do- ing so increases encapsulation, packaging flexibility, and functional extensibility.