Virtual Methods

By declaring a base class function as virtual, you allow the function to be overridden in any derived classes:

class MyBaseClass
{
   public virtual string VirtualMethod()
   {
      return "This method is virtual and defined in MyBaseClass";
   }
}

It is also permitted to declare a property as virtual. For a virtual or overridden property, the syntax is the same as for a nonvirtual property, with the exception of the keyword virtual, which is added to the definition. The syntax looks like this:

public virtual string ForeName
{
   get { return fName;}
   set { fName = value;}
}
private string foreName;

For simplicity, the following discussion focuses mainly on methods, but it applies equally well to properties.

The concepts behind virtual functions in C# are identical to standard OOP concepts. You can override a virtual function in a derived class, and when the method is called, the appropriate method for the type of object is invoked. In C#, functions are not virtual by default but (aside from constructors) can be explicitly declared as virtual. This follows the C++ methodology: for performance reasons, functions are not virtual unless indicated. In Java, by contrast, all functions are virtual. C# differs from C++ syntax, however, because it requires you to declare when a derived class’s function overrides another function, using the override keyword:

class MyDerivedClass : MyBaseClass
{
   public override string VirtualMethod()
   {
      return "This method is an override defined in MyDerivedClass.";
   }
}

This syntax for method overriding removes potential runtime bugs that can easily occur in C++, when a method signature in a derived class unintentionally differs slightly from the base version, resulting in the method failing to override the base version. In C# this is picked up as a compile-time error, because the compiler would see a function marked as override but no base method for it to override.

Neither member fields nor static functions can be declared as virtual. The concept simply wouldn’t make sense for any class member other than an instance function member.

Hiding Methods

If a method with the same signature is declared in both base and derived classes, but the methods are not declared as virtual and override, respectively, then the derived class version is said to hide the base class version.

In most cases, you would want to override methods rather than hide them; by hiding them you risk calling the “wrong” method for a given class instance. However, as shown in the following example, C# syntax is designed to ensure that the developer is warned at compile time about this potential problem, thus making it safer to hide methods if that is your intention. This also has versioning benefits for developers of class libraries.

Suppose that you have a class called HisBaseClass:

class HisBaseClass
{
   // various members
}

At some point in the future you write a derived class that adds some functionality to HisBaseClass. In particular, you add a method called MyGroovyMethod(), which is not present in the base class:

class MyDerivedClass: HisBaseClass
{
   public int MyGroovyMethod()
   {
      // some groovy implementation
      return 0;
   }
}

One year later, you decide to extend the functionality of the base class. By coincidence, you add a method that is also called MyGroovyMethod() and has the same name and signature as yours, but probably doesn’t do the same thing. When you compile your code using the new version of the base class, you have a potential clash because your program won’t know which method to call. It’s all perfectly legal C#, but because your MyGroovyMethod() is not intended to be related in any way to the base class MyGroovyMethod(), the result is that running this code does not yield the result you want. Fortunately, C# has been designed in such a way that it copes very well when conflicts of this type arise.

In these situations, C# generates a compilation warning. That reminds you to use the new keyword to declare that you intend to hide a method, like this:

class MyDerivedClass : HisBaseClass
{
   public new int MyGroovyMethod()
   {
      // some groovy implementation
      return 0;
   }
}

However, because your version of MyGroovyMethod() is not declared as new, the compiler will pick up on the fact that it’s hiding a base class method without being instructed to do so and generate a warning (this applies whether or not you declared MyGroovyMethod() as virtual). If you want, you can rename your version of the method. This is the recommended course of action, because it will eliminate future confusion. However, if you decide not to rename your method for whatever reason (for example, if you’ve published your software as a library for other companies, so you can’t change the names of methods), all your existing client code will still run correctly, picking up your version of MyGroovyMethod(). That’s because any existing code that accesses this method must be doing so through a reference to MyDerivedClass (or a further derived class).

Your existing code cannot access this method through a reference to HisBaseClass; it would generate a compilation error when compiled against the earlier version of HisBaseClass. The problem can only happen in client code you have yet to write. C# arranges things so that you get a warning that a potential problem might occur in future code - and you will need to pay attention to this warning, and take care not to attempt to call your version of MyGroovyMethod() through any reference to HisBaseClass in any future code you add. However, all your existing code will still work fine. It may be a subtle point, but it’s quite an impressive example of how C# is able to cope with different versions of classes.

Calling Base Versions of Functions

C# has a special syntax for calling base versions of a method from a derived class: base.<MethodName>(). For example, if you want a method in a derived class to return 90 percent of the value returned by the base class method, you can use the following syntax:

class CustomerAccount
{
   public virtual decimal CalculatePrice()
   {
      // implementation
      return 0.0M;
   }
}
class GoldAccount : CustomerAccount
{
   public override decimal CalculatePrice()
   {
      return base.CalculatePrice() * 0.9M;
   }
}

Java uses a similar syntax, with the exception that Java uses the keyword super rather than base. C++ has no similar keyword but instead requires specification of the class name (CustomerAccount:: CalculatePrice()). Any equivalent to base in C++ would have been ambiguous because C++ supports multiple inheritance.

Note that you can use the base.<MethodName>() syntax to call any method in the base class - you don’t have to call it from inside an override of the same method.

Abstract Classes and Functions

C# allows both classes and functions to be declared as abstract. An abstract class cannot be instantiated, whereas an abstract function does not have an implementation, and must be overridden in any non-abstract derived class. Obviously, an abstract function is automatically virtual (although you don’t need to supply the virtual keyword; doing so results in a syntax error). If any class contains any abstract functions, that class is also abstract and must be declared as such:

abstract class Building
{
   public abstract decimal CalculateHeatingCost();   // abstract method
}

C++ developers will notice some syntactical differences in C# here. C# does not support the =0 syntax to declare abstract functions. In C#, this syntax would be misleading because =<value> is allowed in member fields in class declarations to supply initial values:

abstract class Building
{
   private bool damaged = false;   // field
   public abstract decimal CalculateHeatingCost();   // abstract method
}

Sealed Classes and Methods

C# allows classes and methods to be declared as sealed. In the case of a class, this means that you can’t inherit from that class. In the case of a method, this means that you can’t override that method.

sealed class FinalClass
{
   // etc
}
class DerivedClass : FinalClass       // wrong. Will give compilation error
{
   // etc
}

The most likely situation in which you’ll mark a class or method as sealed will be if the class or method is internal to the operation of the library, class, or other classes that you are writing, so you are sure that any attempt to override some of its functionality will cause problems. You might also mark a class or method as sealed for commercial reasons, in order to prevent a third party from extending your classes in a manner that is contrary to the licensing agreements. In general, however, you should be careful about marking a class or member as sealed, because by doing so you are severely restricting how it can be used. Even if you don’t think it would be useful to inherit from a class or override a particular member of it, it’s still possible that at some point in the future someone will encounter a situation you hadn’t anticipated in which it is useful to do so. The .NET base class library frequently uses sealed classes in order to make these classes inaccessible to third-party developers who might want to derive their own classes from them. For example, string is a sealed class.

Declaring a method as sealed serves a similar purpose as for a class, although you rarely will want to declare a method as sealed.

class MyClass
{
   public sealed override void FinalMethod()
   {
      // etc.
   }
}
class DerivedClass : MyClass
{
   public override void FinalMethod()      // wrong. Will give compilation error
   {
   }
}

It does not make sense to use the sealed keyword on a method unless that method is itself an override of another method in some base class. If you are defining a new method and you don’t want anyone else to override it, you would not declare it as virtual in the first place. If, however, you have overridden a base class method, the sealed keyword provides a way of ensuring that the override you supply to a method is a “final” override in the sense that no one else can override it again.

Constructors of Derived Classes

Chapter 3 discusses how constructors can be applied to individual classes. An interesting question arises as to what happens when you start defining your own constructors for classes that are part of a hierarchy, inherited from other classes that may also have custom constructors.

Assume you have not defined any explicit constructors for any of your classes. This means that the compiler supplies default zeroing-out constructors for all your classes. There is actually quite a lot going on under the hood when that happens, but the compiler is able to arrange it so that things work out nicely throughout the class hierarchy and every field in every class gets initialized to whatever its default value is. When you add a constructor of your own, however, you are effectively taking control of construction. This has implications right down through the hierarchy of derived classes, and you have to make sure that you don’t inadvertently do anything to prevent construction through the hierarchy from taking place smoothly.

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, that 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.
}

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 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. Then 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.

The net result of all this is that the constructors are called in order of System.Object first, then progressing down the hierarchy until the compiler reaches the class being instantiated. Notice also that in this process, each constructor handles initialization of the fields in its own class. That’s how it should normally work, and when you start adding your own constructors you should try to stick to that principle.

Notice the order in which this happens. It’s always the base class constructors that get called first. This means that there are no problems with a constructor for a derived class invoking any base class methods, properties, and any other members that it has access to, because it can be confident that the base class has already been constructed and its fields initialized. It also means that if the derived class doesn’t like the way that the base class has been initialized, it can change the initial values of the data, provided that it has access to do so. However, good programming practice almost invariably means you’ll try to prevent that situation from occurring if you can, and you will trust the base class constructor to deal with its own fields.

Now that you know how the process of construction works, you can start fiddling with it by adding your own constructors.

public abstract class GenericCustomer
{
   private string name;
   public GenericCustomer()
      : base()  // We could omit this line without affecting the compiled code.
   {
      name = "<no name>";
   }

public GenericCustomer()
{
   name = "<no name>";
}

private GenericCustomer()
{
   name = "<no name>";
}

'Wrox.ProCSharp.GenericCustomer()' is inaccessible due to its protection level

abstract class GenericCustomer
{
   private string name;
   public GenericCustomer(string name)
   {
      this.name = name;
   }

class Nevermore60Customer : GenericCustomer
{
   private uint highCostMinutesUsed;
   public Nevermore60Customer(string name)
      :   base(name)
   {
   }

class Nevermore60Customer : GenericCustomer
{
   public Nevermore60Customer(string name, string referrerName)
      : base(name)
   {
      this.referrerName = referrerName;
   }

   private string referrerName;
   private uint highCostMinutesUsed;

public Nevermore60Customer(string name)
   : this(name, "<None>")
{
}

GenericCustomer customer = new Nevermore60Customer("Arabel Jones");

public Nevermore60Customer(string Name)
   : this(Name, "<None>")