The singly-rooted hierarchy

One of the issues in OOP that has become especially prominent since the introduction of
C++ is whether all classes should ultimately be inherited from a single base class. In Java (as
with virtually all other OOP languages) the answer is “yes” and the name of this ultimate
base class is simply Object. It turns out that the benefits of the singly-rooted hierarchy are
many.
All objects in a singly-rooted hierarchy have an interface in common, so they are all
ultimately the same type. The alternative (provided by C++) is that you don’t know that
everything is the same fundamental type. From a backwards-compatibility standpoint this
fits the model of C better and can be thought of as less restrictive, but when you want to do
full-on object-oriented programming you must then build your own hierarchy to provide
the same convenience that’s built into other OOP languages. And in any new class library
you acquire, some other incompatible interface will be used. It requires effort (and possibly
multiple inheritance) to work the new interface into your design. Is the extra “flexibility” of
Chapter 1: Introduction to Objects 53
C++ worth it? If you need it – if you have a large investment in C – it’s quite valuable. If
you’re starting from scratch, other alternatives such as Java can often be more productive.
All objects in a singly-rooted hierarchy (such as Java provides) can be guaranteed to have
certain functionality. You know you can perform certain basic operations on every object in
your system. A singly-rooted hierarchy, along with creating all objects on the heap, greatly
simplifies argument passing (one of the more complex topics in C++).
A singly-rooted hierarchy makes it much easier to implement a garbage collector. The
necessary support can be installed in the base class, and the garbage collector can thus send
the appropriate messages to every object in the system. Without a singly-rooted hierarchy
and a system to manipulate an object via a handle, it is difficult to implement a garbage
collector.
Since run-time type information is guaranteed to be in all objects, you’ll never end up with
an object whose type you cannot determine. This is especially important with system level
operations, such as exception handling, and to allow greater flexibility in programming.
You may wonder why, if it’s so beneficial, a singly-rooted hierarchy isn’t it in C++. It’s the
old bugaboo of efficiency and control. A singly-rooted hierarchy puts constraints on your
program designs, and in particular it was perceived to put constraints on the use of existing
C code. These constraints cause problems only in certain situations, but for maximum
flexibility there is no requirement for a singly-rooted hierarchy in C++. In Java, which
started from scratch and has no backward-compatibility issues with any existing language,
it was a logical choice to use the singly-rooted hierarchy in common with most other objectoriented
programming languages.