What Is an Object?

An object is a building block of an OOP application. This building block encapsulates part of the application, which can be a process, a chunk of data, or a more abstract entity.

In the simplest sense, an object can be very similar to a struct type such as those shown earlier in the book, containing members of variable and function types. The variables contained make up the data stored in the object, and the functions contained allow access to the object's functionality. Slightly more complex objects might not maintain any data; instead, they can represent a process by containing only functions. For example, an object representing a printer might be used, which would have functions enabling control over a printer (so you can print a document, a test page, and so on).

Objects in C# are created from types, just like the variables you've seen already. The type of an object is known by a special name in OOP, its class. You can use class definitions to instantiate objects, which means creating a real, named instance of a class. The phrases instance of a class and object mean the same thing here; but class and object mean fundamentally different things.

In this chapter, you work with classes and objects using Unified Modeling Language (UML) syntax. UML is designed for modeling applications, from the objects that build them to the operations they perform to the use cases that are expected. Here, you use only the basics of this language, which are explained as you go along. UML is a specialized subject to which entire books are devoted, so it's more complex aspects are not covered here.

Figure 8.1 shows a UML representation of your printer class, called Printer. The class name is shown in the top section of this box (you learn about the bottom two sections a little later).

Figure 8.2 shows a UML representation of an instance of this Printer class called myPrinter.

Here, the instance name is shown first in the top section, followed by the name of its class. The two names are separated by a colon.

Properties and Fields

Properties and fields provide access to the data contained in an object. This object data differentiates separate objects because it is possible for different objects of the same class to have different values stored in properties and fields.

The various pieces of data contained in an object together make up the state of that object. Imagine an object class that represents a cup of coffee, called CupOfCoffee. When you instantiate this class (that is, create an object of this class), you must provide it with a state for it to be meaningful. In this case, you might use properties and fields to enable the code that uses this object to set the type of coffee used, whether the coffee contains milk and/or sugar, whether the coffee is instant, and so on. A given coffee cup object would then have a given state, such as “Colombian filter coffee with milk and two sugars.”

Both fields and properties are typed, so you can store information in them as string values, as int values, and so on. However, properties differ from fields in that they don't provide direct access to data. Objects can shield users from the nitty-gritty details of their data, which needn't be represented on a one-to-one basis in the properties that exist. If you used a field for the number of sugars in a CupOfCoffee instance, then users could place whatever values they liked in the field, limited only by the limits of the type used to store this information. If, for example, you used an int to store this data, then users could use any value between −2147483648 and 2147483647, as shown in Chapter 3. Obviously, not all values make sense, particularly the negative ones, and some of the large positive amounts might require an inordinately large cup. If you use a property for this information, you could limit this value to, say, a number between 0 and 2.

In general, it is better to provide properties rather than fields for state access because you have more control over various behaviors. This choice doesn't affect code that uses object instances because the syntax for using properties and fields is the same.

Read/write access to properties can also be clearly defined by an object. Certain properties can be read-only, allowing you to see what they are but not change them (at least not directly). This is often a useful technique for reading several pieces of state simultaneously. You might have a read-only property of the CupOfCoffee class called Description, returning a string representing the state of an instance of this class (such as the string given earlier) when requested. You might be able to assemble the same data by interrogating several properties, but a property such as this one might save you time and effort. You might also have write-only properties that operate in a similar way.

As well as this read/write access for properties, you can also specify a different sort of access permission for both fields and properties, known as accessibility. Accessibility determines which code can access these members — that is, whether they are available to all code (public), only to code within the class (private), or should use a more complex scheme (covered in more detail later in the chapter, when it becomes pertinent). One common practice is to make fields private and provide access to them via public properties. This means that code within the class has direct access to data stored in the field, while the public property shields external users from this data and prevents them from placing invalid content there. Public members are said to be exposed by the class.

One way to visualize this is to equate it with variable scope. Private fields and properties, for example, can be thought of as local to the object that possesses them, whereas the scope of public fields and properties also encompasses code external to the object.

In the UML representation of a class, you use the second section to display properties and fields, as shown in Figure 8.3.

This is a representation of the CupOfCoffee class, with five members (properties or fields, because no distinction is made in UML) defined as discussed earlier. Each of the entries contains the following information:

• Accessibility — A + symbol is used for a public member, a − symbol is used for a private member. In general, though, private members are not shown in the diagrams in this chapter because this information is internal to the class. No information is provided as to read/write access.
• The member name.
• The type of the member.

A colon is used to separate the member names and types.

Methods

Method is the term used to refer to functions exposed by objects. These can be called in the same way as any other function and can use return values and parameters in the same way — you looked at functions in detail in Chapter 6.

Methods are used to provide access to the object's functionality. Like fields and properties, they can be public or private, restricting access to external code as necessary. They often make use of an object's state to affect their operations, and have access to private members, such as private fields, if required. For example, the CupOfCoffee class might define a method called AddSugar(), which would provide a more readable syntax for incrementing the amount of sugar than setting the corresponding Sugar property.

In UML, class boxes show methods in the third section, as shown in Figure 8.4.

The syntax here is similar to that for fields and properties, except that the type shown at the end is the return type, and method parameters are shown. Each parameter is displayed in UML with one of the following identifiers: return, in, out, or inout. These are used to signify the direction of data flow, where out and inout roughly correspond to the use of the C# keywords out and ref described in Chapter 6. in roughly corresponds to the default C# behavior, where neither the out nor ref keyword is used and return signifies that a value is passed back to the calling method.

Everything's an Object

At this point, it's time to come clean: You have been using objects, properties, and methods throughout this book. In fact, everything in C# and the .NET Framework is an object! The Main() function in a console application is a method of a class. Every variable type you've looked at is a class. Every command you have used has been a property or a method, such as <String>.Length, <String>.ToUpper(), and so on. (The period character here separates the object instance's name from the property or method name, and methods are shown with () at the end to differentiate them from properties.)

Objects really are everywhere, and the syntax to use them is often very simple. It has certainly been simple enough for you to concentrate on some of the more fundamental aspects of C# up until now. From this point on, you'll begin to look at objects in detail. Bear in mind that the concepts introduced here have far-reaching consequences — applying even to that simple little int variable you've been happily playing around with.

The Life Cycle of an Object

Every object has a clearly defined life cycle. Apart from the normal state of “being in use,” this life cycle includes two important stages:

• Construction — When an object is first instantiated it needs to be initialized. This initialization is known as construction and is carried out by a constructor function, often referred to simply as a constructor for convenience.
• Destruction — When an object is destroyed, there are often some clean-up tasks to perform, such as freeing memory. This is the job of a destructor function, also known as a destructor.

CupOfCoffee myCup = new CupOfCoffee();

CupOfCoffee myCup = new CupOfCoffee("Blue Mountain");

Static and Instance Class Members

As well as having members such as properties, methods, and fields that are specific to object instances, it is also possible to have static (also known as shared, particularly to our Visual Basic brethren) members, which can be methods, properties, or fields. Static members are shared between instances of a class, so they can be thought of as global for objects of a given class. Static properties and fields enable you to access data that is independent of any object instances, and static methods enable you to execute commands related to the class type but not specific to object instances. When using static members, in fact, you don't even need to instantiate an object.

For example, the Console.WriteLine() and Convert.ToString() methods you have been using are static. At no point do you need to instantiate the Console or Convert classes (indeed, if you try, you'll find that you can't, as the constructors of these classes aren't publicly accessible, as discussed earlier).

There are many situations such as these where static properties and methods can be used to good effect. For example, you might use a static property to keep track of how many instances of a class have been created. In UML syntax, static members of classes appear with underlining, as shown in Figure 8.5.

Interfaces

An interface is a collection of public instance (that is, nonstatic) methods and properties that are grouped together to encapsulate specific functionality. After an interface has been defined, you can implement it in a class. This means that the class will then support all of the properties and members specified by the interface.

Interfaces cannot exist on their own. You can't “instantiate an interface” as you can a class. In addition, interfaces cannot contain any code that implements its members; it just defines the members. The implementation must come from classes that implement the interface.

In the earlier coffee example, you might group together many of the more general-purpose properties and methods into an interface, such as AddSugar(), Milk, Sugar, and Instant. You could call this interface something like IHotDrink (interface names are normally prefixed with a capital I). You could use this interface on other objects, perhaps those of a CupOfTea class. You could therefore treat these objects in a similar way, and they can still have their own individual properties (BeanType for CupOfCoffee and LeafType for CupOfTea, for example).

Interfaces implemented on objects in UML are shown using lollipop syntax. In Figure 8.6, members of IHotDrink are split into a separate box using class-like syntax.

A class can support multiple interfaces, and multiple classes can support the same interface. The concept of an interface, therefore, makes life easier for users and other developers. For example, you might have some code that uses an object with a certain interface. Provided that you don't use other properties and methods of this object, it is possible to replace one object with another (code using the IHotDrink interface shown earlier could work with both CupOfCoffee and CupOfTea instances, for example). In addition, the developer of the object itself could supply you with an updated version of an object, and as long as it supports an interface already in use, it would be easy to use this new version in your code.

Once an interface is published — that is, it has been made available to other developers or end users — it is good practice not to change it. One way of thinking about this is to imagine the interface as a contract between class creators and class consumers. You are effectively saying, “Every class that supports interface X will support these methods and properties.” If the interface changes later, perhaps due to an upgrade of the underlying code, this could cause consumers of that interface to run it incorrectly, or even fail. Instead, you should create a new interface that extends the old one, perhaps including a version number, such as X2. This has become the standard way of doing things, and you are likely to come across numbered interfaces frequently.

<ClassName> <VariableName> = new <ClassName>();
…
using (<VariableName>)
{
   …
}

using (<ClassName> <VariableName> = new <ClassName>())
{
   …
}

Inheritance

Inheritance is one of the most important features of OOP. Any class may inherit from another, which means that it will have all the members of the class from which it inherits. In OOP terminology, the class being inherited from (derived from) is the parent class (also known as the base class). Classes in C# can derive only from a single base class directly, although of course that base class can have a base class of its own, and so on.

Inheritance enables you to extend or create more specific classes from a single, more generic base class. For example, consider a class that represents a farm animal (as used by ace octogenarian developer Old MacDonald in his livestock application). This class might be called Animal and possess methods such as EatFood() or Breed(). You could create a derived class called Cow, which would support all of these methods but might also supply its own, such as Moo() and SupplyMilk(). You could also create another derived class, Chicken, with Cluck() and LayEgg()methods.

In UML, you indicate inheritance using arrows, as shown in Figure 8.7.

When using inheritance from a base class, the question of member accessibility becomes an important one. Private members of the base class are not accessible from a derived class, but public members are. However, public members are accessible to both the derived class and external code. Therefore, if you could use only these two levels of accessibility, you couldn't have a member that was accessible both by the base class and the derived class but not external code.

To get around this, there is a third type of accessibility, protected, in which only derived classes have access to a member. As far as external code is aware, this is identical to a private member — it doesn't have access in either case.

As well as defining the protection level of a member, you can also define an inheritance behavior for it. Members of a base class can be virtual, which means that the member can be overridden by the class that inherits it. Therefore, the derived class can provide an alternative implementation for the member. This alternative implementation doesn't delete the original code, which is still accessible from within the class, but it does shield it from external code. If no alternative is supplied, then any external code that uses the member through the derived class automatically uses the base class implementation of the member.

In the animals example, you could make EatFood() virtual and provide a new implementation for it on any derived class — for example, just on the Cow class, as shown in Figure 8.8. This displays the EatFood() method on the Animal and Cow classes to signify that they have their own implementations.

Base classes may also be defined as abstract classes. An abstract class can't be instantiated directly; to use it you need to inherit from it. Abstract classes can have abstract members, which have no implementation in the base class, so an implementation must be supplied in the derived class. If Animal were an abstract class, then the UML would look as shown in Figure 8.9.

In Figure 8.9, both EatFood()and Breed()are shown in the derived classes Chicken and Cow, implying that these methods are either abstract (and, therefore, must be overridden in derived classes) or virtual (and, in this case, have been overridden in Chicken and Cow). Of course, abstract base classes can provide implementation of members, which is very common. The fact that you can't instantiate an abstract class doesn't mean you can't encapsulate functionality in it.

Finally, a class may be sealed. A sealed class cannot be used as a base class, so no derived classes are possible.

C# provides a common base class for all objects called object (which is an alias for the System.Object class in the .NET Framework). You take a closer look at this class in Chapter 9.

Polymorphism

One consequence of inheritance is that classes deriving from a base class have an overlap in the methods and properties that they expose. Because of this, it is often possible to treat objects instantiated from classes with a base type in common using identical syntax. For example, if a base class called Animal has a method called EatFood(), then the syntax for calling this method from the derived classes Cow and Chicken will be similar:

Cow myCow = new Cow();
Chicken myChicken = new Chicken();
myCow.EatFood();
myChicken.EatFood();

Polymorphism takes this a step further. You can assign a variable that is of a derived type to a variable of one of the base types, as shown here:

Animal myAnimal = myCow;

No casting is required for this. You can then call methods of the base class through this variable:

myAnimal.EatFood();

This results in the implementation of EatFood() in the derived class being called. Note that you can't call methods defined on the derived class in the same way. The following code won't work:

myAnimal.Moo();

However, you can cast a base type variable into a derived class variable and call the method of the derived class that way:

Cow myNewCow = (Cow)myAnimal;
myNewCow.Moo();

This casting causes an exception to be raised if the type of the original variable was anything other than Cow or a class derived from Cow. There are ways to determine the type of an object, which you'll learn in the next chapter.

Polymorphism is an extremely useful technique for performing tasks with a minimum of code on different objects descending from a single class. It isn't just classes sharing the same parent class that can make use of polymorphism. It is also possible to treat, say, a child and a grandchild class in the same way, as long as there is a common class in their inheritance hierarchy.

As a further note here, remember that in C# all classes derive from the base class object at the root of their inheritance hierarchies. It is therefore possible to treat all objects as instances of the class object. This is how WriteLine()can process an almost infinite number of parameter combinations when building strings. Every parameter after the first is treated as an object instance, allowing output from any object to be written to the screen. To do this, the method ToString() (a member of object) is called. You can override this method to provide an implementation suitable for your class, or simply use the default, which returns the class name (qualified according to any namespaces it is in).

Cow myCow = new Cow();
Chicken myChicken = new Chicken();
IConsume consumeInterface;
consumeInterface = myCow;
consumeInterface.EatFood();
consumeInterface = myChicken;
consumeInterface.EatFood();

VenusFlyTrap myVenusFlyTrap = new VenusFlyTrap();
IConsume consumeInterface;
consumeInterface = myVenusFlyTrap;
consumeInterface.EatFood();

Relationships between Objects

Inheritance is a simple relationship between objects that results in a base class being completely exposed by a derived class, where the derived class can also have some access to the inner workings of its base class (through protected members). There are other situations in which relationships between objects become important.

This section takes a brief look at the following

• Containment — One class contains another. This is similar to inheritance but allows the containing class to control access to members of the contained class and even perform additional processing before using members of a contained class.
• Collections — One class acts as a container for multiple instances of another class. This is similar to having arrays of objects, but collections have additional functionality, including indexing, sorting, resizing, and more.

Containment

Containment is simple to achieve by using a member field to hold an object instance. This member field might be public, in which case users of the container object have access to its exposed methods and properties, much like with inheritance. However, you won't have access to the internals of the class via the derived class, as you would with inheritance.

Alternatively, you can make the contained member object a private member. If you do this, then none of its members will be accessible directly by users, even if they are public. Instead, you can provide access to these members using members of the containing class. This means that you have complete control over which members of the contained class to expose, if any, and you can perform additional processing in the containing class members before accessing the contained class members.

For example, a Cow class might contain an Udder class with the public method Milk(). The Cow object could call this method as required, perhaps as part of its SupplyMilk() method, but these details will not be apparent (or important) to users of the Cow object.

Contained classes can be visualized in UML using an association line. For simple containment, you label the ends of the lines with 1s, showing a one-to-one relationship (one Cow instance will contain one Udder instance). You can also show the contained Udder class instance as a private field of the Cow class for clarity (see Figure 8.10).

Collections

Chapter 5 described how you can use arrays to store multiple variables of the same type. This also works for objects (remember, the variable types you have been using are really objects, so this is no real surprise). Here's an example:

Animal[] animals = new Animal[5];

A collection is basically an array with bells and whistles. Collections are implemented as classes in much the same way as other objects. They are often named in the plural form of the objects they store — for example, a class called Animals might contain a collection of Animal objects.

The main difference from arrays is that collections usually implement additional functionality, such as Add() and Remove() methods to add and remove items to and from the collection. There is also usually an Item property that returns an object based on its index. More often than not this property is implemented in such a way as to allow more sophisticated access. For example, it would be possible to design Animals so that a given Animal object could be accessed by its name.

In UML you can visualize this as shown in Figure 8.11. Members are not included in Figure 8.11 because it's the relationship that is being illustrated. The numbers on the ends of the connecting lines show that one Animals object will contain zero or more Animal objects. You take a more detailed look at collections in Chapter 11.

Operator Overloading

Earlier in the book, you saw how operators can be used to manipulate simple variable types. There are times when it is logical to use operators with objects instantiated from your own classes. This is possible because classes can contain instructions regarding how operators should be treated.

For example, you might add a new property to the Animal class called Weight. You could then compare animal weights using the following:

if (cowA.Weight > cowB.Weight)
{
   …
}

Using operator overloading, you can provide logic that uses the Weight property implicitly in your code, so that you can write code such as the following:

if (cowA > cowB)
{
   …
}

Here, the greater-than operator (>) has been overloaded. An overloaded operator is one for which you have written the code to perform the operation involved — this code is added to the class definition of one of the classes that it operates on. In the preceding example, you are using two Cow objects, so the operator overload definition is contained in the Cow class. You can also overload operators to work with different classes in the same way, where one (or both) of the class definitions contains the code to achieve this.

You can only overload existing C# operators in this way; you can't create new ones. However, you can provide implementations for both unary (single operand) and binary (two operands) usages of operators such as + or >. You see how to do this in C# in Chapter 13.

Events

Objects can raise (and consume) events as part of their processing. Events are important occurrences that you can act on in other parts of code, similar to (but more powerful than) exceptions. You might, for example, want some specific code to execute when an Animal object is added to an Animals collection, where that code isn't part of either the Animals class or the code that calls the Add() method. To do this, you need to add an event handler to your code, which is a special kind of function that is called when the event occurs. You also need to configure this handler to listen for the event you are interested in.

You can create event-driven applications, which are far more prolific than you might think. For example, bear in mind that Windows-based applications are entirely dependent on events. Every button click or scroll bar drag you perform is achieved through event handling, as the events are triggered by the mouse or keyboard.

Later in this chapter you will see how this works in Windows applications, and there is a more in-depth discussion of events in Chapter 13.

Reference Types versus Value Types

Data in C# is stored in a variable in one of two ways, depending on the type of the variable. This type will fall into one of two categories: reference or value. The difference is as follows:

• Value types store themselves and their content in one place in memory.
• Reference types hold a reference to somewhere else in memory (called the heap) where content is stored.

In fact, you don't have to worry about this too much when using C#. So far, you've used string variables (which are reference types) and other simple variables (most of which are value types, such as int) in pretty much the same way.

One key difference between value types and reference types is that value types always contain a value, whereas reference types can be null, reflecting the fact that they contain no value. It is, however, possible to create a value type that behaves like a reference type in this respect (that is, it can be null) by using nullable types. These are described in Chapter 12, when you look at the advanced technique of generic types (which include nullable types).

The only simple types that are reference types are string and object, although arrays are implicitly reference types as well. Every class you create will be a reference type, which is why this is stressed here.