Enumerations

An enumeration is a special kind of value type limited to a restricted and unchangeable set of numerical values. By default, these numerical values are integers, but they can also be longs, bytes, etc. (any numerical value except char) as will be illustrated below.
When you define an enumeration you provide literals which are then used as constants for their corresponding values. The following code shows an example of such a definition:

1. public enum DAYS 2. { 3.     Monday, 4.     Tuesday, 5.     Wednesday, 6.     Thursday, 7.     Friday, 8.     Saturday, 9.     Sunday 10. }

Note, however, that there are no numerical values specified in the above. Instead, the numerical values are (we think) set up according to the following two rules:

1. For the first literal: if it is unassigned, set its value to 0.

2. For any other literal: if it is unassigned, then set its value to one greater than the value of the preceding literal.

From these two rules, it can be seen that DAYS.Monday will be set to 0, and the values increased until DAYS.Sunday is set to 6. Note also how we are referring to these values - the values specified in an enumeration are static, so we have to refer to them in code using the name of the enumeration: "DAYS.Monday" rather than just "Monday". Furthermore, these values are final - you can't change their runtime value.

The following code demonstrates how you can override the default setting which makes the default values integers. In this example, the enumeration values are set to bytes.

1. enum byteEnum : byte 2. { 3.     A, 4.     B 5. }

You can also override the default numerical values of any and all of the enumeration elements. In the following example, the first literal is set to value 1. The other literals are then set up according to the second rule given above, so DAYS.Sunday will end up equal to 7.

1. public enum DAYS 2. { 3.     Monday=1, 4.     Tuesday, 5.     Wednesday, 6.     Thursday, 7.     Friday, 8.     Saturday, 9.     Sunday 10. }

In the two examples given, the values of each literal has been unique within the enumeration. This is usually how you will want things to be, but in fact the values need not be unique. In the following case, the value of DAYS.Thursday is also set to equal 1. The values assigned to the other literals will follow the rules given previously, so both DAYS.Tuesday and DAYS.Friday will equal 2, etc.

1. public enum DAYS 2. { 3.     Monday=1, 4.     Tuesday, 5.     Wednesday, 6.     Thursday=1, 7.     Friday, 8.     Saturday, 9.     Sunday 10. }

In C# enumerations are type-safe, by which we mean that the compiler will do its best to stop you assigning illicit values to enumeration typed variables. For instance, the following code should not compile:

1. int i = DAYS.Monday; 2. DAYS d = i;

In order to get this code to compile, you would have to make explicit casts both ways (even converting from DAYS to int), ie:

1. int i = (int)DAYS.Monday; 2. DAYS d = (DAYS)i;

At this point you may be wondering what happens if you cast an int to an enumeration value where that same value is defined for two elements within the enumeration. And the answer is this: one of the elements is given 'primary' status, so it gets picked ahead of the other.

A useful feature of enumerations is that one can retrieve the literal as a string from the numeric constant with which it is associated. In fact, this is given by the default ToString() method, so the following expression comes out as true:

DAYS.Monday.ToString()=="Monday"

The following code prints out both the literal and its constant value for the specified enumeration.

1. using System; 2. public class EnumTest 3. { 4.     public enum DAYS: byte 5.     {Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday} 6.      7.     public static void Main() 8.     { 9.         Array dayArray = Enum.GetValues(typeof(EnumTest.DAYS)); 10.         foreach (DAYS day in dayArray) 11.             Console.WriteLine("Number {1} of EnumTest.DAYS is {0}", day, day.ToString("d")); 12.     } 13. }

Since it's not immediately obvious what's going on in the main method here, let's take the time to go through it.

On line 9 we use the static GetValues method of the Enum class. When you pass this class an enumeration type - in this case, the type corresponding to EnumTest.DAYS - it returns an array of all the values of the elements within that enumeration. Note that the Enum class also has the GetNames method, which returns the literal strings.

On line 10 we set up a foreach loop, pulling out, into day, each value in the dayArray in turn. Note that this value is of type DAYS.

On line 11 we use string interpolation as part of the Console.WriteLine method. This method makes use of the String.Format method, so is equivalent to:

Console.WriteLine(String.Format("Number {1} of EnumTest.DAYS is {0}", day, day.ToString("d")));

And what the String.Format method does is to take 'textual representations' of the objects it is passed as parameters, and slots them into the appropriate places within the 'format string' it is passed. So this line of code is basically equivalent to:

Console.WriteLine("Number " + day.ToString("d").ToString() + " of EnumTest.DAYS is " + day.ToString());

Now, we've already noted that day.ToString() will return a literal string, but what about the method day.ToString("d")? Well, we had a stab at explaining this a while ago, but did very badly. In fact, we just made an error. So hopefully the following will be better.

The ToString method can take a single IFormatProvider parameter which indicates how the string conversion should be conducted. Values for this parameter can include things like "g", "d", "x", "f", etc. The stated implication of "d", however, is to render in 'Decimal format'. And when we use this on an enumeration member, it provides a string representation of the *numerical value* of the enumeration member. So, when we run the code above, what we get is the following output:

Number 0 of EnumTest.DAYS is Monday
Number 1 of EnumTest.DAYS is Tuesday
Number 2 of EnumTest.DAYS is Wednesday
Number 3 of EnumTest.DAYS is Thursday
Number 4 of EnumTest.DAYS is Friday
Number 5 of EnumTest.DAYS is Saturday
Number 6 of EnumTest.DAYS is Sunday

Properties

Another type of class member is the property. A property combines a field with the methods that access it. As some examples earlier in this book have shown, often you will want to create a field that is available to users of an object, but you want to maintain control over the operations allowed on that field. For instance, you might want to limit the range of values that can be assigned to that field. While it is possible to accomplish this goal through the use of a private variable along with methods to access its value, a property offers a better, more streamlined approach.

Properties are similar to indexers. A property consists of a name along with get and set accessors. The accessors are used to get and set the value of a variable. The key benefit of a property is that its name can be used in expressions and assignments like a normal variable, but in actuality the get and set accessors are automatically invoked. This is similar to the way that an indexer’s get and set accessors are automatically used.

The general form of a property is shown here:

type name {

    get {

        // get accessor code

    }

    set {

        // set accessor code

    }

}

Here, type specifies the type of the property, such as int, and name is the name of the property. Once the property has been defined, any use of name results in a call to its appropriate accessor. The set accessor automatically receives a parameter called value that contains the value being assigned to the property.

It is important to understand that properties do not define storage locations. Thus, a property manages access to a field. It does not, itself, provide that field. The field must be specified independently of the property.

Here is a simple example that defines a property called MyProp, which is used to access the field prop. In this case, the property allows only positive values to be assigned.

// A simple property example.

using System;

class SimpProp {

  int prop; // field being managed by MyProp

  public SimpProp() { prop = 0; }

  /* This is the property that supports access to

     the private instance variable prop.  It

     allows only positive values. */

  public int MyProp {

    get {

      return prop;

    }

    set {

      if(value >= 0) prop = value;

    }

  }

}

// Demonstrate a property.

class PropertyDemo {

  public static void Main() {

    SimpProp ob = new SimpProp();

    Console.WriteLine("Original value of ob.MyProp: " + ob.MyProp);

    ob.MyProp = 100; // assign value

    Console.WriteLine("Value of ob.MyProp: " + ob.MyProp);

    // Can't assign negative value to prop

    Console.WriteLine("Attempting to assign -10 to ob.MyProp");

    ob.MyProp = -10;

    Console.WriteLine("Value of ob.MyProp: " + ob.MyProp);

  }

}

Output from this program is shown here:

Original value of ob.MyProp: 0

Value of ob.MyProp: 100

Attempting to assign -10 to ob.MyProp

Value of ob.MyProp: 100

Let’s examine this program carefully. The program defines one private field, called prop, and a property called MyProp that manages access to prop. As explained, a property by itself does not define a storage location. A property simply manages access to a field. Thus, there is no concept of a property without an underlying field. Furthermore, because prop is private, it can be accessed only through MyProp.

The property MyProp is specified as public so that it can be accessed by code outside of its class. This makes sense because it provides access to prop, which is private. The get accessor simply returns the value of prop. The set accessor sets the value of prop if and only if that value is positive. Thus, the MyProp property controls what values prop can have. This is the essence of why properties are important.

The type of property defined by MyProp is called a read-write property because it allows its underlying field to be read and written. It is possible, however, to create read-only and write-only properties. To create a read-only property, define only a get accessor. To define a write-only property, define only a set accessor.

You can use a property to further improve the fail-soft array class. As you know, all arrays have a Length property associated with them. Up to now, the FailSoftArray class simply used a public integer field called Length for this purpose. This is not good practice, though, because it allows Length to be set to some value other than the length of the fail-soft array. (For example, a malicious programmer could intentionally corrupt its value.) We can remedy this situation by transforming Length into a read-only property, as shown in the following version of FailSoftArray:

// Add Length property to FailSoftArray.

using System;

class FailSoftArray {

  int[] a; // reference to underlying array

  int len; // length of array -- underlies Length property

  public bool errflag; // indicates outcome of last operation

  // Construct array given its size.

  public FailSoftArray(int size) {

    a = new int[size];

    len = size;

  }

  // Read-only Length property.

  public int Length {

    get {

      return len;

    }

  }

  // This is the indexer for FailSoftArray.

  public int this[int index] {

    // This is the get accessor.

    get {

      if(ok(index)) {

        errflag = false;

        return a[index];

      } else {

        errflag = true;

        return 0;

      }

    }

    // This is the set accessor

    set {

      if(ok(index)) {

        a[index] = value;

        errflag = false;

      }

      else errflag = true;

    }

  }

  // Return true if index is within bounds.

  private bool ok(int index) {

   if(index >= 0 & index < Length) return true;

   return false;

  }

}

// Demonstrate the improved fail-soft array.

class ImprovedFSDemo {

  public static void Main() {

    FailSoftArray fs = new FailSoftArray(5);

    int x;

    // can read Length

    for(int i=0; i < fs.Length; i++)

      fs[i] = i*10;

    for(int i=0; i < fs.Length; i++) {

      x = fs[i];

      if(x != -1) Console.Write(x + " ");

    }

    Console.WriteLine();

    // fs.Length = 10; // Error, illegal!

  }

}

Length is now a property that uses the private variable len for its storage. Length defines only a get accessor, which means that it is read-only. Thus, Length can be read, but not changed. To prove this to yourself, try removing the comment symbol preceding this line in the program:

// fs.Length = 10; // Error, illegal!

When you try to compile, you will receive an error message stating that Length is read-only.

Although the addition of the Length property improves FailSoftArray, it is not the only improvement that properties can make. The errflag member is also a prime candidate for conversion into a property since access to it should also be limited to read-only. Here is the final improvement of FailSafeArray. It creates a property called Error that uses the original errflag variable as its storage.

// Convert errflag into a property.

using System;

class FailSoftArray {

  int[] a; // reference to underlying array

  int len; // length of array

  bool errflag; // now private

  // Construct array given its size.

  public FailSoftArray(int size) {

    a = new int[size];

    len = size;

  }

  // Read-only Length property.

  public int Length {

    get {

      return len;

    }

  }

  // Read-only Error property.

  public bool Error {

    get {

      return errflag;

    }

  }

  // This is the indexer for FailSoftArray.

  public int this[int index] {

    // This is the get accessor.

    get {

      if(ok(index)) {

        errflag = false;

        return a[index];

      } else {

        errflag = true;

        return 0;

      }

    }

    // This is the set accessor

    set {

      if(ok(index)) {

        a[index] = value;

        errflag = false;

      }

      else errflag = true;

    }

  }

  // Return true if index is within bounds.

  private bool ok(int index) {

   if(index >= 0 & index < Length) return true;

   return false;

  }

}

// Demonstrate the improved fail-soft array.

class FinalFSDemo {

  public static void Main() {

    FailSoftArray fs = new FailSoftArray(5);

    // use Error property

    for(int i=0; i < fs.Length + 1; i++) {

      fs[i] = i*10;

      if(fs.Error)

        Console.WriteLine("Error with index " + i);

    }

  }

}

The creation of the Error property has caused two changes to be made to FailSoftArray. First, errflag has been made private because it is now used as the underlying storage for the Error property. Thus, it won’t be available directly. Second, the read-only Error property has been added. Now, programs that need to detect errors will interrogate Error. This is demonstrated in Main( ), where a boundary error is intentionally generated, and the Error property is used to detect it.

Property Restrictions

Properties have some important restrictions. First, because a property does not define a storage location, it cannot be passed as a ref or out parameter to a method. Second, you cannot overload a property. (You can have two different properties that both access the same variable, but this would be unusual.) Finally, a property should not alter the state of the underlying variable when the get accessor is called. Although this rule is not enforced by the compiler, violating it is wrong. A get operation should be nonintrusive.

Using Access Modifiers with Accessors

Beginning with C# 2.0, you can specify an access modifier, such as private, when declaring a get or set accessor. Doing so enables you to control access to an accessor. For example, you might want to make set private to prevent the value of a property or an indexer from being set by code outside its class. In this case, the property or indexer could be read by any code, but set only by a member of its class.

Here is an example:

// Use an access modifier with an accessor.

using System;

class PropAccess {

  int prop; // field being managed by MyProp

  public PropAccess() { prop = 0; }

  /* This is the property that supports access to

     the private instance variable prop.  It allows

     any code to obtain the value of prop, but

     only other class members can set the value

     of prop. */

  public int MyProp {

    get {

      return prop;

    }

    private set { // now, private

      prop = value;

    }

  }

  // This class member increments the value of MyProp.

  public void incrProp() {

    MyProp++; // OK, in same class.

  }

}

// Demonstrate accessor access modifier.

class PropAccessDemo {

  public static void Main() {

    PropAccess ob = new PropAccess();

    Console.WriteLine("Original value of ob.MyProp: " + ob.MyProp);

//    ob.MyProp = 100; // can't access set

    ob.incrProp();

    Console.WriteLine("Value of ob.MyProp after increment: "

                      + ob.MyProp);

  }

}

In the PropAccess class, the set accessor is specified private. This means that it can be accessed by other class members, such as incrProp( ), but cannot be accessed by code outside of PropAccess. This is why the attempt to assign ob.MyProp a value inside PropAccessDemo is commented out.

Here are some restrictions that apply to using access modifiers with accessors. First, only the set or the get accessor can be modified, not both. Furthermore, the access modifier must be more restrictive than the access level of the property or indexer.

INHERITANCE

INHERITANCE 

Inheritance

The concept of inheritance brings something of a real-world view to programming. It allows a class to be defined which has a number of characteristics and then other classes to be created which are derived from that class. The derived class inherits all of the features of the parent class and typically then adds some features of its own.

By deriving classes we create what is often referred to as a class hierarchy. The class at the top of the hierarchy is known as the base class and the derived classes as subclasses. Any number of classes may be derived from a class. It is only possible for a derived class to inherit from one class. As such, C# is known as a single inheritance programming language.

Classes need not only be derived from a base class. For example, a subclass can also inherit from another subclass.

An Example of Inheritance

As with most programming concepts the subject of inheritance in C# is perhaps best illustrated with an example. In the previous chapter we created a class called BankAccount:

public class BankAccount

{

        public string accountName;

        public int accountFee;

        private int accountBalance;

        private int accountNumber;

        public int getAccountNumber()

        {

               return accountNumber;

        }

        public void setAccountNumber(int newNumber)

        {

               accountNumber = newNumber;

        }

}

This class does a good job of defining characteristics common to any type of bank account, such as account holder name, account number and current balance. Imagine, however, that our banking program needs to support a number of specific types of account. For example, the bank might offer its customers an interest bearing savings account. A savings account will have all the characteristics of our BankAccount class but would also need a way to store the prevailing interest rate. One option would be to create a brand new class from the ground up called SavingsAccount which duplicates everything we have in our BankAccount class, plus extra members needed for a savings account. Another, more efficient method is to derive a SavingsAccount class from the BankAccount class and then add in the extra functionality into this subclass.

Creating a Subclass in C#

Now that we have ascertained that we need to create a sub class of our BankAccount class we can take a look at the code necessary to achieve this. Subclasses are declared in the same way as any other class with the exception that the class name is followed by a colon (:) followed by the name of the class from which it is to inherit. With this in mind we can begin by creating our SavingsAccount class:

public class BankAccount

{

        public string accountName;

        public int accountBalance;

        public int accountNumber;

        public BankAccount (string name, int number)

        {

               accountName = name;

               accountNumber = number;

        }

        public int getAccountNumber()

        {

               return accountNumber;

        }

        public void setAccountNumber(int newNumber)

        {

               accountNumber = newNumber;

        }

}

public class SavingsAccount : BankAccount

{

}

We have now created a sub class of BankAccount called SavingsAccount, but at this point the SavingsAccount class is no different than its parent class. Next we need to add some new members to add the behavior we need:

public class SavingsAccount : BankAccount

{

        public double interestRate;

        public SavingsAccount (string name, int number, int balance, double rate)

               : base (name, number)

        {

               accountBalance = balance;

               interestRate = rate;

        }

        public double monthlyInterest()

        {

               return interestRate * accountBalance;

        }

}

We now have a new class called SavingsAccount which inherits all the members of the BankAccount class and adds some members of its own. In particular we have added a new data member called interestRate which will store the interest rate paid on the account together with a new method to calculate the monthly interest.

Passing Arguments to the Base Class Constructor

Of particular significance is the constructor. In the BankAccount base class we have a constructor which takes the account name and account number as arguments. In the SavingsAccount subclass we need to accept two additional arguments - the balance and the interest rate. The : base code instructs C# to handle the name and number arguments using the constructor from the base class. The remaining two arguments are then passed to the SavingsAccount constructor.

With our subclass complete we can now make use of it:

       static void Main()

        {

          SavingsAccount saveAccount = new SavingsAccount("Aditya Tyagi", 123456, 432, 0.02F);

          Console.WriteLine ("Interest this Month = " + saveAccount.monthlyInterest() );

        }

Anonymous Methods

Anonymous Methods

In the original C# language, to construct a delegate object you have to provide it with the name of a method. The code below shows an example: ‘Print’ is first defined as a particular delegate type, then its instance ‘delegateVariable’ is created by passing it the name of the method ‘realMethod’.

1. delegate void Print (string s); 2. Print delegateVariable = new Print(realMethod); 3. 4. public void realMethod (string myString) 5. { 6.     MessageBox.Show(myString); 7. }

Now, however, C# has been updated to include ‘anonymous’ methods (which should be pretty easy for anyone who has used anonymous functions in languages like Javascript). These allow you to construct a delegate by specifying, rather than just naming a method. The following gives an example of how the above code could be written using an anonymous method:

1. public delegate void Print (string s); 2. Print delegateVariable = delegate(string myString) {MessageBox.Show(myString);};

In the above case, the anonymous method is given the same signature as the delegate it is passed to. But this is not always necessary. For the anonymous method to be acceptable, the following two conditions must be met:

1. Either the anonymous method has a parameter list that exactly matches the delegate’s parameters; or the anonymous method has no parameter list and the delegate has no ‘out’ parameters.

2. Either the values returned by the anonymous method are all of the right type for the delegate; or the anonymous method doesn’t return anything and the delegate’s return type is ‘void’.

An implication of the first condition is that an anonymous method with no parameters at all can fit a delegate with parameters. The following code is thus possible (notice that we’ve had to remove the use of ‘myString’ in the Show method, because we’re no longer passing it in):

1. public delegate void Print (string s); 2. Print delegateVariable = delegate {MessageBox.Show(“hello world!”);};

Outer Types

Anonymous methods can also make use of the local variables and parameters in whose scope the anonymous method lies. This is a somewhat complicated, and we don’t yet have a clear idea of when one should exploit it. So to illustrate it we’ll borrow the example from the documentation.

1. delegate int myDelegate(); 2. class Test 3. { 4.     static myDelegate myFunc() 5.     { 6.         int x=0; 7.         myDelegate result = delegate {return ++x;} 8.         return result; 9.     } 10.      11.     static void Main() 12.     { 13.         myDelegate d = myFunc(); 14.         Console.WriteLine(d()); 15.         Console.WriteLine(d()); 16.         Console.WriteLine(d()); 17.     } 18. }

Here the delegate ‘result’ declared in the function ‘myFunc’ makes use of (in the jargon, captures) the integer ‘x’ which is declared in the same function. Now, if we run the code, the output is this:

1
2
3

This result is somewhat surprising, since the integer ‘x’ is instantiated and its value maintained across three delegate calls after the function myFunc has finished running. How this is described in the documentation is that the lifetime of the captured outer type is ‘extended’, so that it lasts as long as any delegate that references it.

A further point to note is that in the example above each delegate is clearly referencing the same type instance. But there are situations in which local variables get initialized many times within a function, and these variables will count as different type instances. For example, in the following loop, the integer i is initialised three times, and the delegates added into the myDelegateArray will reference different variables.

1. myDelegate[] myDelegateArray = new myDelegate[3]; 2. for (int x=0; x<3; x++) 3. { 4.     int i = x; 5.     myDelegateArray[x] = delegate {return ++i}; 6. }

One question that this naturally raises is whether the multiple initialisation of i gives a performance hit, which one could avoid by declaring i outside the loop. But the documentation suggests that this isn’t the case; each new instance of i just slots neatly into the place vacated by the previous one.