why private part of a class is considered as interface?

Question

I'm reading Grady Booch's book Object-Oriented Analysis and Design with Applications, third edition. In page 94, Booch said that:

We can furthur devide the interface of a class into four parts:

1. Public: a declaration that is accessible to all clients
2. Protected: a declaration that is accessible only to the class itself and its subclasses
3. Private: a declaration that is accessible only to the class itself
4. Package: a declaration that is accessible only by classes in the same package

I can understand why protected declaration can be considered a interface, becuase subclasses of a class is this class's client, too.

But I don't understand why the private declaration can be considered as interface. Please enlight me.

Answer 1

But I don't understand why the private declaration can be considered as interface.

Private declarations may be said to constitute an interface, since they have their own clients, though not as many as protected or public interface of a class.

These clients are:

1. The class itself. Obviously, you can access your classes' private members from any static or non-static method of any instance of your class.
2. Inner classes of your class. Remember that inner classes of your class have access to all of the members of your class, including private ones.
3. (In C++) Friends of your class. Though from the quote in your question, I see that the book you refer to is about Java, I'll add this item anyway, for completeness, since your question isn't tagged java. In C++ there is a friend keyword, which allows a programmer of a class to designate certain other classes and/or functions as friends of this class. Such "friendly" classes and functions have access to all the members of the class, including private ones, and so they are also clients of the class' private interface.

So, it may be useful to have a well-defined private interface, since it makes the implementation of methods in both your class, its friends and inner classes simpler and more manageable for other developers, who may be working on your class.

---

But still, I find an "interface to itself" is quite odd.

Interface to itself may be important. Here's a little thought experiment.

Imagine that two developers, Alice and Bob, are working on the same class, called MissileLauncher. Bob is responsible for implementing the logic to clear the launching pad after the missile is fired. (This is a private mechanism, clients of the public or protected interface may not request the pad to be cleared - it's just an implementation detail of this class).

So, Bob knows that to clear the launching pad one has to decrement missleCounter, set currentMissle to null and call pendingOperations.remove(this.currentOp). There is only one place in the code of the class, where this has to be done. Bob could encapsulate all of this in a private method, called clearLaunchingPad() but he figured that the logic is too simple, so he didn't bother.

Several months later, Alice discovers that there is another scenario, where the launching pad needs to be cleared. If Bob had thought about a proper "interface to itself", Alice would be able to simply write a call to this.clearLaunchingPad() and be done with it in several seconds. But, as we know, Bob didn't. Now Alice has to go and ask Bob what she needs to do to clear the pad. But several months have already passed, Bob doesn't remember the implementation details anymore, or worse, he may have been fired since then (and no surprise either, given his coding culture).

So now Alice has to dig into the code of MissileLauncher and try to figure out what she needs to do, hoping that Bob has at least had the decency to comment his code.

In this way several seconds turn into several hours and a few possible bugs (Alice might forget to call pendingOperations.remove(this.currentOp) at the end), just because Bob didn't pay attention to the design of this class` interface to itself.