C# 4 and .NET 4

implementation inheritance ❘ 95
You might be wondering why there is any special problem with derived classes. The reason is that when you
create an instance of a derived class, there is actually more than one constructor at work. The constructor of
the class you instantiate isn’t by itself sufficient to initialize the class — the constructors of the base classes
must also be called. That’s why we’ve been talking about construction through the hierarchy.
To see why base class constructors must be called, you’re going to develop an example based on a cell phone
company called MortimerPhones. The example contains an abstract base class, GenericCustomer, which
represents any customer. There is also a (non-abstract) class, Nevermore60Customer, which represents any
customer on a particular rate called the Nevermore60 rate. All customers have a name, represented by a
private field. Under the Nevermore60 rate, the first few minutes of the customer’s call time are charged at
a higher rate, necessitating the need for the field highCostMinutesUsed, which details how many of these
higher-cost minutes each customer has used up. The class definitions look like this:
abstract class GenericCustomer
{
private string name;
// lots of other methods etc.
}
class Nevermore60Customer: GenericCustomer
{
private uint highCostMinutesUsed;
// other methods etc.
}
code snippet MortimerPhones.cs
We won’t worry about what other methods might be implemented in these classes, because we are
concentrating solely on the construction process here. And if you download the sample code for this chapter,
you’ll find that the class definitions include only the constructors.
Take a look at what happens when you use the new operator to instantiate a Nevermore60Customer:
GenericCustomer customer = new Nevermore60Customer();
Clearly, both of the member fields name and highCostMinutesUsed must be initialized when customer is
instantiated. If you don’t supply constructors of your own, but rely simply on the default constructors, then
you’d expect name to be initialized to the null reference, and highCostMinutesUsed initialized to zero.
Let’s look in a bit more detail at how this actually happens.
The highCostMinutesUsed field presents no problem: the default Nevermore60Customer constructor
supplied by the compiler will initialize this field to zero.
What about name Looking at the class definitions, it’s clear that the Nevermore60Customer constructor
can’t initialize this value. This field is declared as private, which means that derived classes don’t have access
to it. So, the default Nevermore60Customer constructor simply won’t know that this field exists. The only
code items that have that knowledge are other members of GenericCustomer. This means that if name is
going to be initialized, that’ll have to be done by some constructor in GenericCustomer. No matter how big
your class hierarchy is, this same reasoning applies right down to the ultimate base class, System.Object.
Now that you have an understanding of the issues involved, you can look at what actually happens whenever a
derived class is instantiated. Assuming that default constructors are used throughout, the compiler first grabs
the constructor of the class it is trying to instantiate, in this case Nevermore60Customer. The first thing that
the default Nevermore60Customer constructor does is attempt to run the default constructor for the immediate
base class, GenericCustomer. The GenericCustomer constructor attempts to run the constructor for its
immediate base class, System.Object. System.Object doesn’t have any base classes, so its constructor just
executes and returns control to the GenericCustomer constructor. That constructor now executes, initializing
name to null, before returning control to the Nevermore60Customer constructor. That constructor in turn
executes, initializing highCostMinutesUsed to zero, and exits. At this point, the Nevermore60Customer
instance has been successfully constructed and initialized.
www.it-ebooks.info