Defining Fields

Fields are defined using standard variable declaration format (with optional initialization), along with the modifiers discussed previously:

class MyClass
{
   public int MyInt;
}

Fields can also use the keyword readonly, meaning the field can be assigned a value only during constructor execution or by initial assignment:

class MyClass
{
   public readonly int MyInt = 17;
}

As noted in the chapter introduction, fields can be declared as static using the static keyword:

class MyClass
{
   public static int MyInt;
}

Static fields are accessed via the class that defines them (MyClass.MyInt in the preceding example), not through object instances of that class. You can use the keyword const to create a constant value. const members are static by definition, so you don't need to use the static modifier (in fact, it is an error to do so).

Defining Methods

Methods use standard function format, along with accessibility and optional static modifiers, as shown in this example:

class MyClass
{
   public string GetString() => return "Here is a string.";
}

Remember that if you use the static keyword, then this method is accessible only through the class, not the object instance. You can also use the following keywords with method definitions:

• virtual — The method can be overridden.
• abstract — The method must be overridden in non-abstract derived classes (only permitted in abstract classes).
• override — The method overrides a base class method (it must be used if a method is being overridden).
• extern — The method definition is found elsewhere.

Here's an example of a method override:

public class MyBaseClass
{
   public virtual void DoSomething()
   {
      // Base implementation.
   }
}
public class MyDerivedClass : MyBaseClass
{
   public override void DoSomething()
   {
      // Derived class implementation, overrides base implementation.
   }
}

If override is used, then sealed can also be used to specify that no further modifications can be made to this method in derived classes — that is, the method can't be overridden by derived classes. Here is an example:

public class MyDerivedClass : MyBaseClass
{
   public override sealed void DoSomething()
   {
      // Derived class implementation, overrides base implementation.
   }
}

Using extern enables you to provide the implementation of a method externally to the project, but this is an advanced topic not covered here.

Defining Properties

Properties are defined in a similar way to fields, but there's more to them. Properties, as already discussed, are more involved than fields in that they can perform additional processing before modifying state — and, indeed, might not modify state at all. They achieve this by possessing two function-like blocks: one for getting the value of the property and one for setting the value of the property.

These blocks, also known as accessors, are defined using get and set keywords respectively, and can be used to control the access level of the property. You can omit one or the other of these blocks to create read-only or write-only properties (where omitting the get block gives you write-only access, and omitting the set block gives you read-only access). Of course, that only applies to external code because code elsewhere within the class will have access to the same data that these code blocks have. You can also include accessibility modifiers on accessors — making a get block public while the set block is protected, for example. You must include at least one of these blocks to obtain a valid property (and, let's face it, a property you can't read or change wouldn't be very useful).

The basic structure of a property consists of the standard access modifying keyword (public, ­private, and so on), followed by a type name, the property name, and one or both of the get and set blocks that contain the property processing:

public int MyIntProp
{
   get
   {
      // Property get code.
   }
   set
   {
      // Property set code.
   }
}

The first line of the definition is the bit that is very similar to a field definition. The difference is that there is no semicolon at the end of the line; instead, you have a code block containing nested get and set blocks.

get blocks must have a return value of the type of the property. Simple properties are often associated with a single private field controlling access to that field, in which case the get block can return the field's value directly:

// Field used by property.
private int myInt;
// Property.
public int MyIntProp
{
   get { return myInt; }
   set { // Property set code. }
}

Code external to the class cannot access this myInt field directly due to its accessibility level (it is private). Instead, external code must use the property to access the field. The set function assigns a value to the field similarly. Here, you can use the keyword value to refer to the value received from the user of the property:

// Field used by property.
private int myInt;
// Property.
public int MyIntProp
{
   get { return myInt; }
   set { myInt = value; }
}

value equates to a value of the same type as the property, so if the property uses the same type as the field, then you never have to worry about casting in situations like this.

This simple property does little more than shield direct access to the myInt field. The real power of properties is apparent when you exert a little more control over the proceedings. For example, you might implement your set block as follows:

   set
   {
      if (value >= 0 && value <= 10)
         myInt = value;
   }

Here, you modify myInt only if the value assigned to the property is between 0 and 10. In situations like this, you have an important design choice to make. What should you do if an invalid value is used? You have four options:

• Do nothing (as in the preceding code).
• Assign a default value to the field.
• Continue as if nothing went wrong but log the event for future analysis.
• Throw an exception.

In general, the last two options are preferable. Deciding between them depends on how the class will be used and how much control should be assigned to the users of the class. Exception throwing gives users a fair amount of control and lets them know what is going on so that they can respond appropriately. You can use one of the standard exceptions in the System namespace for this:

   set
   {
      if (value >= 0 && value <= 10)
         myInt = value;
      else
         throw (new ArgumentOutOfRangeException("MyIntProp", value,
                   "MyIntProp must be assigned a value between 0 and 10."));
   }

This can be handled using try…catch…finally logic in the code that uses the property, as you saw in Chapter 7.

Logging data, perhaps to a text file, can be useful, such as in production code where problems really shouldn't occur. It enables developers to check on performance and perhaps debug existing code if necessary.

Properties can use the virtual, override, and abstract keywords just like methods, something that isn't possible with fields. Finally, as mentioned earlier, accessors can have their own accessibilities, as shown here:

// Field used by property.
private int myInt;
// Property.
public int MyIntProp
{
   get { return myInt; }
   protected set { myInt = value; }
}

Here, only code within the class or derived classes can use the set accessor.

The accessibilities that are permitted for accessors depend on the accessibility of the property, and it is forbidden to make an accessor more accessible than the property to which it belongs. This means that a private property cannot contain any accessibility modifiers for its accessors, whereas public properties can use all modifiers on their accessors.

C# 6 introduced a feature called expression based properties. Similar to the expression based method discussed previously in Chapter 6, this feature reduces the extent of the property to a single line of code. For example, properties that return a one-line mathematical computation on a value can use the lambda arrow followed by the equation.

// Field used by property.
private int myDoubledInt = 5;
// Property.
public int MyDoubledIntProp => (myDoubledInt * 2);

The following Try It Out enables you to experiment with defining and using fields, methods, and properties.

Refactoring Members

One technique that comes in handy when adding properties is the capability to generate a property from a field. This is an example of refactoring, which simply means modifying your code using a tool, rather than by hand. This can be accomplished by right-clicking a member in a class diagram or in code view.

For example, if the MyClass class contained the field,

public string myString;

you could right-click on the field and select Quick Actions…. That would bring up the dialog box shown in Figure 10.2.

Accepting the default options modifies the code for MyClass as follows:

public string myString;
public string MyString
{
   get { return myString; }
   set { myString = value; }
}
private string myString;

Here, the accessibility of the myString field has been changed to private, and a public property called MyString has been created and automatically linked to myString. Clearly, reducing the time required to monotonously create properties for fields is a big plus!

Automatic Properties

Properties are the preferred way to access the state of an object because they shield external code from the implementation of data storage within the object. They also give you greater control over how internal data is accessed, as you have seen several times in this chapter's code. However, you'll typically define properties in a very standard way — that is, you will have a private member that is accessed directly through a public property. The code for this is almost invariably similar to the code in the previous section, which was autogenerated by the Visual Studio refactoring tool.

Refactoring certainly speeds things up when it comes to typing, but C# has another trick up its sleeve: automatic properties. With an automatic property, you declare a property with a simplified syntax and the C# compiler fills in the blanks for you. Specifically, the compiler declares a private field that is used for storage, and uses that field in the get and set blocks of your property — without you having to worry about the details.

Use the following code structure to define an automatic property:

public int MyIntProp
{
   get;
   set;
}

You can even define an automatic property on a single line of code to save space, without making the property much less readable:

public int MyIntProp { get; set; }

You define the accessibility, type, and name of the property in the usual way, but you don't provide any implementation for the get or set block. Instead, the compiler provides the implementations of these blocks (and the underlying field).

When you use an automatic property, you only have access to its data through the property, not through its underlying private field. This is because you can't access the private field without ­knowing its name, which is defined during compilation. However, that's not really a limitation because using the property name directly is fine. The only limitation of automatic properties is that they must include both a get and a set accessor — you cannot define read- or write-only properties in this way. However, you can change the accessibility of these accessors. For example, this means you can create an externally read-only property as follows:

public int MyIntProp { get; private set; }

Here you can access the value of MyIntProp only from code in the class definition.

C# 6 introduced two new concepts pertaining to automatic properties referred to as getter-only auto-properties and initializers for auto-properties. Prior to C# 6, automatic properties required ­setters, which limited the utilization of immutable data types. The simple definition of an immutable data type is that it does not change state once it is created, the most famous immutable type being System.String. There are many benefits for using immutable data types, such as the simplification of concurrent programming and the synchronization of threads.

Concurrent programming and synchronization of threads are advanced topics and not discussed further in this book; however, it is important to know about the getter-only auto-properties. They are created by using the following syntax, notice that a setter is no longer required:

public int MyIntProp { get; }

The initialization feature for auto-properties is implemented by the following which is similar to the way fields are declared:

public int MyIntProp { get; } = 9;

Hiding Base Class Methods

When you inherit a (non-abstract) member from a base class, you also inherit an implementation. If the inherited member is virtual, then you can override this implementation with the override ­keyword. Regardless of whether the inherited member is virtual, you can, if you want, hide the implementation. This is useful when, for example, a public inherited member doesn't work quite as you want it to.

You can do this simply by using code such as the following:

public class MyBaseClass
{
   public void DoSomething()
   {
      // Base implementation.
   }
}
public class MyDerivedClass : MyBaseClass
{
   public void DoSomething()
   {
      // Derived class implementation, hides base implementation.
   }
}

Although this code works fine, it generates a warning that you are hiding a base class member. That warning gives you the chance to correct it if you have accidentally hidden a member that you want to use. If you really do want to hide the member, you can use the new keyword to explicitly indicate that this is what you want to do:

public class MyDerivedClass : MyBaseClass
{
   new public void DoSomething()
   {
      // Derived class implementation, hides base implementation.
   }
}

This works in exactly the same way but won't show a warning. At this point, it's worthwhile to note the difference between hiding and overriding base class members. Consider the following code:

public class MyBaseClass
{
   public virtual void DoSomething() => WriteLine("Base imp");
}
public class MyDerivedClass : MyBaseClass
{
   public override void DoSomething() => WriteLine("Derived imp");
}

Here, the overriding method replaces the implementation in the base class, such that the following code uses the new version even though it does so through the base class type (using polymorphism):

MyDerivedClass myObj = new MyDerivedClass();
MyBaseClass myBaseObj;
myBaseObj = myObj;
myBaseObj.DoSomething();

This results in the following output:

Derived imp

Alternatively, you could hide the base class method:

public class MyBaseClass
{
   public virtual void DoSomething() => WriteLine("Base imp");
}
public class MyDerivedClass : MyBaseClass
{
   new public void DoSomething() => WriteLine("Derived imp");
}

The base class method needn't be virtual for this to work, but the effect is exactly the same and the preceding code only requires changes to one line. The result for a virtual or nonvirtual base class method is as follows:

Base imp

Although the base implementation is hidden, you still have access to it through the base class.

Calling Overridden or Hidden Base Class Methods

Whether you override or hide a member, you still have access to the base class member from the derived class. There are many situations in which this can be useful, such as the following:

• When you want to hide an inherited public member from users of a derived class but still want access to its functionality from within the class
• When you want to add to the implementation of an inherited virtual member rather than simply replace it with a new overridden implementation

To achieve this, you use the base keyword, which refers to the implementation of the base class ­contained within a derived class (in a similar way to its use in controlling constructors, as shown in the last chapter):

public class MyBaseClass
{
   public virtual void DoSomething()
   {
      // Base implementation.
   }
}
public class MyDerivedClass : MyBaseClass
{
   public override void DoSomething()
   {
      // Derived class implementation, extends base class implementation.
      base.DoSomething();
      // More derived class implementation.
   }
}

This code executes the version of DoSomething() contained in MyBaseClass, the base class of MyDerivedClass, from within the version of DoSomething() contained in MyDerivedClass. As base works using object instances, it is an error to use it from within a static member.

   public void doSomething()
   {
      MyTargetClass myObj = new MyTargetClass();
      myObj.DoSomethingWith(this);
   }

public class MyClass
{
   private int someData;
   public int SomeData
   {
      get
      {
         return this.someData;
      }
   }
}

Using Nested Type Definitions

You can define types such as classes in namespaces, and you can also define them inside other classes. Then you can use the full range of accessibility modifiers for the definition, rather than just public and internal, and you can use the new keyword to hide a type definition inherited from a base class. For example, the following code defining MyClass also defines a nested class called MyNestedClass:

public class MyClass
{
   public class MyNestedClass
   {
      public int NestedClassField;
   }
}

To instantiate MyNestedClass from outside MyClass, you must qualify the name, as shown here:

MyClass.MyNestedClass myObj = new MyClass.MyNestedClass();

However, you might not be able to do this, for example if the nested class is declared as private. One reason for the existence of this feature is to define classes that are private to the containing class so that no other code in the namespace has access to them. Another reason is that nested classes have access to private and protected members of their containing class. The next Try it Out ­examines this feature.

Implementing Interfaces in Classes

A class that implements an interface must contain implementations for all members of that interface, which must match the signatures specified (including matching the specified get and set blocks), and must be public, as shown here:

public interface IMyInterface
{
   void DoSomething();
   void DoSomethingElse();
}
public class MyClass : IMyInterface
{
   public void DoSomething() {}
   public void DoSomethingElse() {}
}

It is possible to implement interface members using the keyword virtual or abstract, but not static or const. Interface members can also be implemented on base classes:

public interface IMyInterface
{
   void DoSomething();
   void DoSomethingElse();
}
public class MyBaseClass
{
   public void DoSomething() {}
}
public class MyDerivedClass : MyBaseClass, IMyInterface
{
   public void DoSomethingElse() {}
}

Inheriting from a base class that implements a given interface means that the interface is implicitly supported by the derived class. Here's an example:

public interface IMyInterface
{
   void DoSomething();
   void DoSomethingElse();
}
public class MyBaseClass : IMyInterface
{
   public virtual void DoSomething() {}
   public virtual void DoSomethingElse() {}
}
public class MyDerivedClass : MyBaseClass
{
   public override void DoSomething() {}
}

Clearly, it is useful to define implementations in base classes as virtual so that derived classes can replace the implementation, rather than hide it. If you were to hide a base class member using the new keyword, rather than override it in this way, the method IMyInterface.DoSomething() would always refer to the base class version even if the derived class were being accessed via the interface.

MyClass myObj = new MyClass();
myObj.DoSomething();

MyClass myObj = new MyClass();
IMyInterface myInt = myObj;
myInt.DoSomething();

public class MyClass : IMyInterface
{
   void IMyInterface.DoSomething() {}
   public void DoSomethingElse() {}
}

public interface IMyInterface
{
   int MyIntProperty { get; }
}
public class MyBaseClass : IMyInterface
{
   public int MyIntProperty { get; protected set; }
}

Planning the Application

The class library for this application, Ch10CardLib, will contain your classes. Before you get down to any code, though, you should plan the required structure and functionality of your classes.

The Card Class

The Card class is basically a container for two read-only fields: suit and rank. The reason for ­making the fields read-only is that it doesn't make sense to have a “blank” card, and cards shouldn't be able to change once they have been created. To facilitate this, you'll make the default constructor private, and provide an alternative constructor that builds a card from a supplied suit and rank.

Other than that, the Card class will override the ToString() method of System.Object, so that you can easily obtain a human-readable string representing the card. To make things a little simpler, you'll provide enumerations for the two fields suit and rank.

The Card class is shown in Figure 10-4.

The Deck Class

The Deck class will maintain 52 Card objects. You can use a simple array type for this. The array won't be directly accessible because access to the Card object is achieved through a GetCard()method, which returns the Card object with the given index. This class should also expose a Shuffle() method to rearrange the cards in the array. The Deck class is shown in Figure 10-5.

Writing the Class Library

For the purposes of this example, it is assumed that you are familiar enough with the IDE to bypass the standard Try It Out format, so the steps aren't listed explicitly, as they are the same steps you've used many times. The important thing here is a detailed look at the code. Nonetheless, several pointers are included to ensure that you don't run into any problems along the way.

Both your classes and your enumerations will be contained in a class library project called Ch10CardLib. This project will contain four .cs files: Card.cs, which contains the Card class definition, Deck.cs, which contains the Deck class definition, and the Suit.cs and Rank.cs files ­containing enumerations.

You can put together a lot of this code using the Visual Studio class diagram tool.

To get started, you need to do the following:

1. Create a new class library project called Ch10CardLib and save it in the directory C:BegVCSharpChapter10.
2. Remove Class1.cs from the project.
3. Open the class diagram for the project using the Solution Explorer window (right-click the project and then click View View Class Diagram). The class diagram should be blank to start with because the project contains no classes.

Adding the Suit and Rank Enumerations

You can add an enumeration to the class diagram by dragging an Enum from the Toolbox into the diagram, and then filling in the New Enum dialog box that appears. For example, for the Suit ­enumeration, fill out the dialog box as shown in Figure 10.6.

Next, add the members of the enumeration using the Class Details window. Figure 10.7 shows the values that are required.

Add the Rank enumeration from the Toolbox in the same way. The values required are shown in Figure 10.8.

You can find the code generated for these two enumerations in the code files, Suit.cs and Rank.cs. First, you can find the full code for this example in Ch10CardLib folder/Suit.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Ch10CardLib
{
   public enum Suit
   {
      Club,
      Diamond,
      Heart,
      Spade,
   }
}

And you can find the full code for this example in Ch10CardLib folder/Rank.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Ch10CardLib
{
   public enum Rank
   {
      Ace = 1,
      Deuce,
      Three,
      Four,
      Five,
      Six,
      Seven,
      Eight,
      Nine,
      Ten,
      Jack,
      Queen,
      King,
   }
}

Alternatively, you can add this code manually by adding Suit.cs and Rank.cs code files and then entering the code. Note that the extra commas added by the code generator after the last enumeration member do not prevent compilation and do not result in an additional “empty” member being created — although they are a little messy.

Adding the Card Class

To add the Card class, you'll use a mix of the class designer and code editor. Adding a class in the class designer is much like adding an enumeration — you drag the appropriate entry from the Toolbox into the diagram. In this case, you drag a Class into the diagram and name the new class Card.

Use the Class Details window to add the fields rank and suit, and then use the Properties window to set the Constant Kind of the field to readonly. You also need to add two constructors — a ­private default constructor, and a public constructor that takes two parameters, newSuit and newRank, of types Suit and Rank, respectively. Finally, you override ToString(), which requires you to change the Inheritance Modifier in the Properties window to override.

Figure 10.9 shows the Class Details window and the Card class with all the information entered. (You can find this code in Ch10CardLibCard.cs.)

Next, modify the code for the class in Card.cs as follows (or add the code shown to a new class called Card in the Ch10CardLib namespace):

public class Card
{
   public readonly Suit suit;
   public readonly Rank rank;
   public Card(Suit newSuit, Rank newRank)
   {
      suit = newSuit;
      rank = newRank;
   }
   private Card()
   {
   }
   public override string ToString()
   {
      return "The " + rank + " of " + suit + "s";
   }
}

The overridden ToString() method writes the string representation of the enumeration value stored to the returned string, and the nondefault constructor initializes the values of the suit and rank fields.

Adding the Deck Class

The Deck class needs the following members defined using the class diagram:

• A private field called cards, of type Card[]
• A public default constructor
• A public method called GetCard(), which takes one int parameter called cardNum and returns an object of type Card
• A public method called Shuffle(), which takes no parameters and returns void

When these are added, the Class Details window for the Deck class will appear as shown in Figure 10.10.

To make things clearer in the diagram, you can show the relationships among the members and types you have added. In the class diagram, right-click on each of the following in turn and select Show as Association from the menu:

• cards in Deck
• suit in Card
• rank in Card

When you have finished, the diagram should look like Figure 10.11.

Next, modify the code in Deck.cs (if you aren't using the class designer, you must add this class first with the code shown here). You can find this code in Ch10CardLibDeck.cs. First you implement the constructor, which simply creates and assigns 52 cards in the cards field. You iterate through all combinations of the two enumerations, using each to create a card. This results in cards initially containing an ordered list of cards:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace Ch10CardLib
{
   public class Deck
   {
      private Card[] cards;
      public Deck()
      {
         cards = new Card[52];
         for (int suitVal = 0; suitVal < 4; suitVal++)
         {
            for (int rankVal = 1; rankVal < 14; rankVal++)
            {
               cards[suitVal * 13 + rankVal -1] = new Card((Suit)suitVal,
                                                           (Rank)rankVal);
            }
         }
      }

Next, implement the GetCard() method, which either returns the Card object with the requested index or throws an exception as shown earlier:

      public Card GetCard(int cardNum)
      {
         if (cardNum >= 0 && cardNum <= 51)
            return cards[cardNum];
         else
            throw (new System.ArgumentOutOfRangeException("cardNum", cardNum,
                      "Value must be between 0 and 51."));
      }

Finally, you implement the Shuffle() method. This method works by creating a temporary card array and copying cards from the existing cards array into this array at random. The main body of this function is a loop that counts from 0 to 51. On each cycle, you generate a random number between 0 and 51, using an instance of the System.Random class from the .NET Framework. Once instantiated, an object of this class generates a random number between 0 and X, using the method Next(X). When you have a random number, you simply use that as the index of the Card object in your temporary array in which to copy a card from the cards array.

To keep a record of assigned cards, you also have an array of bool variables, and assign these to true as each card is copied. As you are generating random numbers, you check against this array to see whether you have already copied a card to the location in the temporary array specified by the random number. If so, you simply generate another.

This isn't the most efficient way of doing things because many random numbers will be generated before finding a vacant slot into which a card can be copied. However, it works, it's very simple, and C# code executes so quickly you will hardly notice a delay. The code is as follows:

      public void Shuffle()
      {
         Card[] newDeck = new Card[52];
         bool[] assigned = new bool[52];
         Random sourceGen = new Random();
         for (int i = 0; i < 52; i++)
         {
            int destCard = 0;
            bool foundCard = false;
            while (foundCard == false)
            {
               destCard = sourceGen.Next(52);
               if (assigned[destCard] == false)
                  foundCard = true;
            }
            assigned[destCard] = true;
            newDeck[destCard] = cards[i];
         }
         newDeck.CopyTo(cards, 0);
      }
   }
}

The last line of this method uses the CopyTo() method of the System.Array class (used whenever you create an array) to copy each of the cards in newDeck back into cards. This means you are using the same set of Card objects in the same cards object, rather than creating any new instances. If you had instead used cards = newDeck, then you would be replacing the object instance referred to by cards with another. This could cause problems if code elsewhere were retaining a reference to the original cards instance — which wouldn't be shuffled!

That completes the class library code.

A Client Application for the Class Library

To keep things simple, you can add a client console application to the solution containing the class library. To do so, simply right-click on the solution in Solution Explorer and select Add New Project. The new project is called Ch10CardClient.

To use the class library you have created from this new console application project, add a reference to your Ch10CardLib class library project. You can do that through the Projects tab of the Reference Manager dialog box, as shown in Figure 10.12.

Select the project and click OK to add the reference.

Because this new project is the second one you've created, you also need to specify that it is the startup project for the solution, meaning the one that is executed when you click Run. To do so, simply right-click on the project name in the Solution Explorer window and select the Set as StartUp Project menu option.

Next, add the code that uses your new classes. That doesn't require anything particularly special, so the following code will do (you can find this code in Ch10CardClientProgram.cs):

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using static System.Console;
using Ch10CardLib;
namespace Ch10CardClient
{
   class Program
   {
      static void Main(string[] args)
      {
         Deck myDeck = new Deck();
         myDeck.Shuffle();
         for (int i = 0; i < 52; i++)
         {
            Card tempCard = myDeck.GetCard(i);
            Write(tempCard.ToString());
            if (i != 51)
               Write(", ");
            else
               WriteLine();
         }
         ReadKey();
      }
   }
}

Figure 10.13 shows the result you'll get if you run this application.

This is a random arrangement of the 52 playing cards in the deck. You'll continue to develop and use this class library in later chapters.