Item 30: Avoid member functions that return non-const pointers or references to members less accessible than themselves.
The reason for making a member private or protected is to limit access to it, right? Your overworked, underpaid C++ compilers go to lots of trouble to make sure that your access restrictions aren't circumvented, right? So it doesn't make a lot of sense for you to write functions that give random clients the ability to freely access restricted members, now, does it? If you think it does make sense, please reread this paragraph over and over until you agree that it doesn't.
It's easy to violate this simple rule. Here's an example:
class Address { ... }; // where someone lives
class Person {
public:
Address& personAddress() { return address; }
...
private:
Address address;
...
};
The member function personAddress provides the caller with the Address object contained in the Person object, but, probably due to efficiency considerations, the result is returned by reference instead of by value (see Item 22). Unfortunately, the presence of this member function defeats the purpose of making Person::address private:
Person scott(...); // parameters omitted for
// simplicity
Address& addr = // assume that addr is
scott.personAddress(); // global
Now the global object addr is another name for scott.address, and it can be used to read and write scott.address at will. For all practical purposes, scott.address is no longer private; it is public, and the source of this promotion in accessibility is the member function personAddress. Of course, there is nothing special about the access level private in this example; if address were protected, exactly the same reasoning would apply.
References aren't the only cause for concern. Pointers can play this game, too. Here's the same example, but using pointers this time:
class Person {
public:
Address * personAddress() { return &address; }
...
private:
Address address;
...
};
Address *addrPtr =
scott.personAddress(); // same problem as above
With pointers, however, you have to worry not only about data members, but also about member functions. That's because it's possible to return a pointer to a member function:
class Person; // forward declaration
// PPMF = "pointer to Person member function"
typedef void (Person::*PPMF)();
class Person {
public:
static PPMF verificationFunction()
{ return &Person::verifyAddress; }
...
private:
Address address;
void verifyAddress();
};
If you're not used to socializing with pointers to member functions and typedefs thereof, the declaration for Person::verificationFunction may seem daunting. Don't be intimidated. All it says is
verificationFunction is a member function that takes no parameters;
- its return value is a pointer to a member function of the
Person class;
- the pointed-to function (i.e.,
verificationFunction's return value) takes no parameters and returns nothing, i.e., void.
As for the word static, that means what it always means in a member declaration: there is only one copy of the member for the entire class, and the member can be accessed without an object. For the complete story, consult your favorite introductory C++ textbook. (If your favorite introductory C++ textbook doesn't discuss static members, carefully tear out all its pages and recycle them. Dispose of the book's cover in an environmentally sound manner, then borrow or buy a better textbook.)
In this last example, verifyAddress is a private member function, indicating that it's really an implementation detail of the class; only class members should know about it (and friends, too, of course). However, the public member function verificationFunction returns a pointer to verifyAddress, so clients can again pull this kind of thing:
PPMF pmf = scott.verificationFunction();
(scott.*pmf)(); // same as calling
// scott.verifyAddress
Here, pmf has become a synonym for Person::verifyAddress, with the crucial difference that there are no restrictions on its use.
In spite of the foregoing discussion, you may someday be faced with a situation in which, pressed to achieve performance constraints, you honestly need to write a member function that returns a reference or a pointer to a less-accessible member. At the same time, however, you won't want to sacrifice the access restrictions that private and protected afford you. In those cases, you can almost always achieve both goals by returning a pointer or a reference to a const object. For details, take a look at Item 21.