[Previous] [Contents] [Next]

Singly Rooted Object Hierarchy


As I mentioned earlier, an important CTS characteristic is the singly rooted object hierarchy. In the .NET Framework, every type in the system derives from the System.Object base class. An important diversion from the C++ language, in which there is no implied base class for all classes, this single base class approach is endorsed by OOP theorists and is implemented in most mainstream object-oriented language. The benefits to a singly rooted hierarchy aren't immediately apparent, but over time you'll come to question how languages were designed before this type of hierarchy was adopted.

A singly rooted object hierarchy is the key to a unified type system because it guarantees that each object in the hierarchy has a common interface and therefore everything in the hierarchy will ultimately be of the same base type. One of the main drawbacks of C++ is its lack of support for such a hierarchy. Let's consider a simple example to see what I mean.

Say you've built up an object hierarchy in C++ based on a base class of your own making. We'll call this base class CFoo. Now say you want to integrate with another object hierarchy whose objects all derive from a base class called CBar. In this example, the object hierarchies have incompatible interfaces and it's going to require a lot of effort to integrate these two hierarchies. You might have to use some sort of wrapper class with aggregation or use multiple inheritance to make this work. With a singly rooted hierarchy, compatibility is not an issue because each object has the same interface (inherited from System.Object). As a result, you know that each and every object in your hierarchy-and, crucially, in the hierarchies of third-party .NET code-has a certain minimal set of functionality.

[Previous] [Contents] [Next]