The IS_A relationship between SavingsAccount and BankAccount is demonstrated by the modification to the class Program in the SimpleSavingsAccount program from the preceding section:

public class Program
{
  // Add this:
  // DirectDeposit -- Deposit my paycheck automatically.
  public static void DirectDeposit(BankAccount ba, decimal pay)
  {
    ba.Deposit(pay);
  }
  public static void Main(string[] args)
  {
    // Create a bank account and display it.
    BankAccount ba = new BankAccount();
    ba.InitBankAccount(100M);
    DirectDeposit(ba, 100M);
    Console.WriteLine("Account {0}", ba.ToBankAccountString());
    // Now a savings account
    SavingsAccount sa = new SavingsAccount();
    sa.InitSavingsAccount(12.5M);
    DirectDeposit(sa, 100M);
    sa.AccumulateInterest();
    Console.WriteLine("Account {0}", sa.ToSavingsAccountString());
    // Wait for user to acknowledge the results.
    Console.WriteLine("Press Enter to terminate...");
    Console.Read();
  }
}

In effect, nothing has changed. The only real difference is that all deposits are now being made through the local method DirectDeposit(), which isn't part of class BankAccount. The arguments to this method are the bank account and the amount to deposit.

The class SavingsAccount could have gained access to the members of BankAccount in a different way, as shown in the following code, where the key lines are shown in boldface:

// SavingsAccount -- A bank account that draws interest
public class SavingsAccount_   // Notice the underscore: this isn't
                               // the SavingsAccount class.
{
  public BankAccount _bankAccount;  // Notice this, the contained BankAccount.
  public decimal _interestRate;
  // InitSavingsAccount -- Input the rate expressed as a
  //    rate between 0 and 100.
  public void InitSavingsAccount(BankAccount bankAccount, decimal interestRate)
  {
    this._bankAccount = bankAccount;
    this._interestRate = interestRate / 100;
  }
  // AccumulateInterest -- Invoke once per period.
  public void AccumulateInterest()
  {
    _bankAccount._balance = _bankAccount.Balance
                   + (_bankAccount.Balance * interestRate);
  }
  // Deposit -- Any positive deposit is allowed.
  public void Deposit(decimal amount)
  {
    // Delegate to the contained BankAccount object.
    _bankAccount.Deposit(amount);
  }
  // Withdraw -- You can withdraw any amount up to the
  //    balance; return the amount withdrawn.
  public double Withdraw(decimal withdrawal)
  {
    return _bankAccount.Withdraw(withdrawal);
  }
}

In this case, the class SavingsAccount_ contains a data member _bank Account (as opposed to inheriting from BankAccount). The _bankAccount object contains the balance and account number information needed by the savings account. The SavingsAccount_ class retains the data unique to a savings account and delegates to the contained BankAccount object as needed. That is, when the SavingsAccount needs, say, the balance, it asks the contained BankAccount for it.

In this case, you say that the SavingsAccount_ HAS_A BankAccount. Hard-core object-oriented jocks say that SavingsAccount composes a BankAccount. That is, SavingsAccount is partly composed of a BankAccount.

The HAS_A relationship is fundamentally different from the IS_A relationship. This difference doesn't seem so bad in the following application-code segment example:

// Create a new savings account.
BankAccount ba = new BankAccount()
SavingsAccount_ sa = new SavingsAccount_(); // HAS_A version of SavingsAccount
sa.InitSavingsAccount(ba, 5);
// And deposit 100 dollars into it.
sa.Deposit(100M);
// Now accumulate interest.
sa.AccumulateInterest();

The problem is that this modified SavingsAccount_ cannot be used as a BankAccount because it doesn't inherit from BankAccount. Instead, it contains a BankAccount — not the same concept. For example, this code example fails:

// DirectDeposit -- Deposit my paycheck automatically.
void DirectDeposit(BankAccount ba, int pay)
{
  ba.Deposit(pay);
}
void SomeMethod()
{
  // The following example fails.
  SavingsAccount_ sa = new SavingsAccount_();
  DirectDeposit(sa, 100);
  // . . . continue . . .
}

A program can use a subclass object where a base class object is called for. In fact, you may have already seen this concept in one of my examples. SomeMethod() can pass a SavingsAccount object to the DirectDeposit() method, which expects a BankAccount object.

You can make this conversion more explicit:

BankAccount ba;
SavingsAccount sa = new SavingsAccount(); // The original, not SavingsAccount_
// OK:
ba = sa;                 // Implicitly converting subclass to base class.

ba = (BankAccount)sa;    // But the explicit cast is preferred.
// Not OK:
sa = ba;                 // ERROR: Implicitly converting base class to subclass
sa = (SavingsAccount)ba; // An explicit cast is allowed, however.

The first line stores a SavingsAccount object into a BankAccount variable. C# converts the object for you. The second line uses a cast to explicitly convert the object.

The final two lines attempt to convert the BankAccount object back into SavingsAccount. You can complete this operation explicitly, but C# doesn't do it for you. It's like trying to convert a larger numeric type, such as double, to a smaller one, such as float. C# doesn't do it implicitly because the process involves a loss of data.

Generally, casting an object from BankAccount to SavingsAccount is a dangerous operation. Consider this example:

public static void ProcessAmount(BankAccount bankAccount)
{
  // Deposit a large sum to the account.
  bankAccount.Deposit(10000.00M);
  // If the object is a SavingsAccount, collect interest now.
  SavingsAccount savingsAccount = (SavingsAccount)bankAccount;
  savingsAccount.AccumulateInterest();
}
public static void TestCast()
{
  SavingsAccount sa = new SavingsAccount();
  ProcessAmount(sa);
  BankAccount ba = new BankAccount();
  ProcessAmount(ba);
}

ProcessAmount() performs a few operations, including invoking the AccumulateInterest() method. The cast of ba to a SavingsAccount is necessary because the bankAccount parameter is declared to be a BankAccount. The program compiles properly because all type conversions are made by explicit cast.

All goes well with the first call to ProcessAmount() from within TestCast(). The SavingsAccount object sa is passed to the ProcessAmount() method. The cast from BankAccount to SavingsAccount causes no problem because the ba object was originally a SavingsAccount, anyway.

The second call to ProcessAmount() isn't as lucky, however. The cast to SavingsAccount cannot be allowed. The ba object doesn't have an AccumulateInterest() method.

The ProcessAmount() method would work if it could ensure that the object passed to it is a SavingsAccount object before performing the conversion. C# provides two keywords for this purpose: is and as.

The is operator accepts an object on the left and a type on the right. The is operator returns true if the runtime type of the object on the left is compatible with the type on the right. Use it to verify that a cast is legal before you attempt the cast.

You can modify the example in the previous section to avoid the runtime error by using the is operator:

public static void ProcessAmount(BankAccount bankAccount)
{
  // Deposit a large sum to the account.
  bankAccount.Deposit(10000.00M);
  // If the object is a SavingsAccount . . .
  if (bankAccount is SavingsAccount)
  {
    // ...then collect interest now (cast is guaranteed to work).
    SavingsAccount savingsAccount = (SavingsAccount)bankAccount;
    savingsAccount.AccumulateInterest();
  }
  // Otherwise, don't do the cast -- but why is BankAccount not what
  // you expected? This could be an error situation.
}
public static void TestCast()
{
  SavingsAccount sa = new SavingsAccount();
  ProcessAmount(sa);
  BankAccount ba = new BankAccount();
  ProcessAmount(ba);
}

The added if statement checks the bankAccount object to ensure that it's of the class SavingsAccount. The is operator returns true when ProcessAmount() is called the first time. When passed a BankAccount object in the second call, however, the is operator returns false, avoiding the illegal cast. This version of the program doesn't generate a runtime error.

The as operator works a bit differently from is. Rather than return a bool if the cast would work, it converts the type on the left to the type on the right, but safely returns null if the conversion fails — rather than cause a runtime error. You should always use the result of casting with the as operator only if it isn't null. So, using as looks like this:

SavingsAccount savingsAccount = bankAccount as SavingsAccount;
if(savingsAccount != null)
{
  // Go ahead and use savingsAccount.
}
// Otherwise, don't use it: generate an error message yourself.

The default base class constructor is invoked any time a subclass is constructed. The constructor for the subclass automatically invokes the constructor for the base class, as this simple program demonstrates:

// InheritingAConstructor -- Demonstrate that the base class
//    constructor is invoked automatically.
using System;
namespace InheritingAConstructor
{

public class Program
  {
    public static void Main(string[] args)
    {
      Console.WriteLine("Creating a BaseClass object");
      BaseClass bc = new BaseClass();
      Console.WriteLine("
now creating a SubClass object");
      SubClass sc = new SubClass();
      // Wait for user to acknowledge.
      Console.WriteLine("Press Enter to terminate...");
      Console.Read();
    }
  }
  public class BaseClass
  {
    public BaseClass()
    {
      Console.WriteLine("Constructing BaseClass");
    }
  }
  public class SubClass : BaseClass
  {
    public SubClass()
    {
      Console.WriteLine("Constructing SubClass");
    }
  }
}

The constructors for BaseClass and SubClass do nothing more than output a message to the command line. Creating the BaseClass object invokes the default BaseClass constructor. Creating a SubClass object invokes the BaseClass constructor before invoking its own constructor.

Here's the output from this program:

Creating a BaseClass object
Constructing BaseClass

Now creating a SubClass object
Constructing BaseClass
Constructing SubClass
Press Enter to terminate...

The subclass invokes the default constructor of the base class, unless specified otherwise — even from a subclass constructor other than the default. The following slightly updated example demonstrates this feature:

using System;
namespace Example
{
  public class Program
  {
    public static void Main(string[] args)
    {
      Console.WriteLine("Invoking SubClass() default");
      SubClass sc1 = new SubClass();
      Console.WriteLine("
Invoking SubClass(int)");
      SubClass sc2 = new SubClass(0);
      // Wait for user to acknowledge.
      Console.WriteLine("Press Enter to terminate...");
      Console.Read();
    }
  }
  public class BaseClass
  {
    public BaseClass()
    {
      Console.WriteLine("Constructing BaseClass (default)");
    }
    public BaseClass(int i)
    {
      Console.WriteLine("Constructing BaseClass (int)");
    }
  }
  public class SubClass : BaseClass
  {
    public SubClass()
    {
      Console.WriteLine("Constructing SubClass (default)");
    }
    public SubClass(int i)
    {
      Console.WriteLine("Constructing SubClass (int)");
    }
  }
}

Executing this program generates the following result:

Invoking SubClass()
Constructing BaseClass (default)
Constructing SubClass (default)

Invoking SubClass(int)
Constructing BaseClass (default)
Constructing SubClass (int)
Press Enter to terminate...

The program first creates a default object. As expected, C# invokes the default SubClass constructor, which first passes control to the default BaseClass constructor. The program then creates an object, passing an integer argument. Again as expected, C# invokes the SubClass(int). This constructor invokes the default BaseClass constructor, just as in the earlier example, because it has no data to pass.

A subclass constructor can invoke a specific base class constructor using the keyword base.

For example, consider this small program, InvokeBaseConstructor:

// InvokeBaseConstructor -- Demonstrate how a subclass can
//    invoke the base class constructor of its choice using
//    the base keyword.
using System;
namespace InvokeBaseConstructor
{
  public class BaseClass
  {
    public BaseClass()
    {
      Console.WriteLine("Constructing BaseClass (default)");
    }
    public BaseClass(int i)
    {
      Console.WriteLine("Constructing BaseClass({0})", i);
    }
  }
  public class SubClass : BaseClass
  {
    public SubClass()
    {
      Console.WriteLine("Constructing SubClass (default)");
    }
    public SubClass(int i1, int i2) : base(i1)
    {
      Console.WriteLine("Constructing SubClass({0}, {1})", i1,  i2);
    }
  }
  public class Program
  {
    public static void Main(string[] args)
    {
      Console.WriteLine("Invoking SubClass()");
      SubClass sc1 = new SubClass();

      Console.WriteLine("
invoking SubClass(1, 2)");
      SubClass sc2 = new SubClass(1, 2);

      // Wait for user to acknowledge.
      Console.WriteLine("Press Enter to terminate...");

Console.Read();
    }
  }
}

The output from this program is

Invoking SubClass()
Constructing BaseClass (default)
Constructing SubClass (default)

Invoking SubClass(1, 2)
Constructing BaseClass(1)
Constructing SubClass(1, 2)
Press Enter to terminate...

This version begins the same as the previous examples, by creating a default SubClass object using the default constructor of both BaseClass and SubClass.

The second object is created with the expression new SubClass(1, 2). C# invokes the SubClass(int, int) constructor, which uses the base keyword to pass one of the values to the BaseClass(int) constructor. SubClass passes the first argument to the base class for processing and then uses the second value itself.