5: Hiding the implementation

Bruce Eckel’s Thinking in Java Contents | Prev | Next

A
primary consideration in object-oriented design is “separating the things
that change from the things that stay the same.”

This
is particularly important for libraries. The user (
client
programmer
)
of that library must be able to rely on the part they use, and know that they
won’t need to rewrite code if a new version of the library comes out. On
the flip side, the library creator must have the freedom to make modifications
and improvements with the certainty that the client programmer’s code
won’t be affected by those changes.

This
can be achieved through convention. For example, the library programmer must
agree to not remove existing methods when modifying a class in the library,
since that would break the client programmer’s code. The reverse
situation is thornier, however. In the case of a data member, how can the
library creator know which data members have been accessed by client
programmers? This is also true with methods that are only part of the
implementation of a class, and not meant to be used directly by the client
programmer. But what if the library creator wants to rip out an old
implementation and put in a new one? Changing any of those members might break
a client programmer’s code. Thus the library creator is in a strait
jacket and can’t change anything.

More by Author

Must Read