Back to Item 29: Avoid returning "handles" to internal data.
Continue to Item 31: Never return a reference to a local object or to a dereferenced pointer initialized by new within the function.
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.
Back to Item 29: Avoid returning "handles" to internal data.
Continue to Item 31: Never return a reference to a local object or to a dereferenced pointer initialized by new within the function.