Objects and Classes

It might not seem like it, but object-oriented concepts have been around for nearly 30 years. In the next few sections of this chapter, you will learn the basics of object-oriented programming and its terminology. You will start by defining the terms object, class, attribute, operation, and state. From there, you will learn the specifics of each term and how it is applied in Visual C# .NET. Finally, you will create a straightforward sample application using the techniques you just learned.

OOP BASIC GUIDELINES When first entering the world of object-oriented programming, it can seem overwhelming. Several questions inevitably come to mind: What deserves to be an object? How should I abstract the problem domain? Is this object too big and does it do too much? Should I break it up further? All of these questions are valid and should have specific answers. The easy answer is that an object should do its intended jobno more and no less. The problem arises when you're deciding what the object's intended job involves. This is when many programmers get lost. They code the solution one way, and then go back and do it another way. This continues until they decide that the solution is acceptable. Although refactoring is a good thing (see Martin Fowler's book on the subject), this way of designing is a bit ridiculous, not to mention time-consuming. Fortunately, there is an easier way to create this design. Although many programmers like to dive in, it is more beneficial to take the time to do some upfront design. This can involve a white board, paper, Microsoft Visio, IBM's Rational Rose, or any other tool. The point is to create the design first. This enables you to easily scrap what you have and start over. It doesn't matter how good you are, you will change your design many times. If you don't, there's something suspicious and you should rethink your position.

Class Attributes

This next section will show you what attributes are, and how they carry over from the design board into code as properties and fields.

Definition

The definition of attribute varies slightly depending on whether you consult a dictionary or whether you consult the MSDN documentation. A dictionary definition says that an attribute is a quality or characteristic inherent in someone or something. This applies to classes when you are designing. When designing classes, you ascribe to those classes attributes that fit the model being designed. When you get to the coding phase, attributes (qualities or characteristics) become properties and fields of a class or object.

Description of an Attribute

An attribute is a physical characteristic of a class or object (the terms class and object are defined later in this section). That characteristic can be something as simple as the color of the object or as complex as a contained object or class. Unlike a class or object, an attribute has no identity outside of the class or object that contains it. For example, the color red, outside of a representation of a bicycle, does not have an identity. However, as part of an instance of a bicycle, the color red makes up an essential part of the object's state (object state is described later in this section).

Design and UML Notation of Attributes

In UML, an attribute begins with a lowercase letter. This type of capitalization is sometimes referred to as camel case. An attribute is also prefaced by a scope indicator:

+, -, or #. Each symbol corresponds to an appropriate scoping type: public, private, and protected, respectively. Figure 6.1 shows four private attributes inside a class definition. Although public is a valid scoping operator for attributes, it is considered extremely bad object-oriented programming practice to use it because doing so violates encapsulation.

Examples of Attributes

The examples in Table 6.1 show attributes and their corresponding declarations in Visual C#.

Table 6.1. UML Attribute Design Versus Code

UML Notation	Visual C# Declaration
-birthDate	private DateTime m_birthDate;
-hairColor	private string hairColor = "blue";
#lastName	protected string m_lastName = "Kruger";
#firstName	protected string m_firstName = "Lonny";
+badAttribute	public string m_badAttribute = "should never use public attributes";

Operations in Object-Oriented Design and Programming

Where you can think of attributes as characteristics that can be represented with nouns (age, height, weight, sex, and so on), operations are actions that an object performs, and can therefore be represented by verbs (run, walk, jump, calculate, and the like).

An operation is a service exposed by a class or object. When an object receives a message from another object, the receiving object knows exactly which operation corresponds to that message and it invokes the desired action. This is possible because each class definition contains operation signatures. An operation signature consists of its name, return type, and any parameters that may be passed to it. Because of the information that makes up a signature, one class definition can contain multiple operations with the same name. However, it is not possible to have multiple operations with the same signature.

UML Notation for Operations

In UML, an operation follows the following form and is listed in the third compartment of a class as shown in Figure 6.2:

Name(argument : ArgumentType = DefaultValue, ...):
  ReturnType {PropertyValues} {Constraints}

In Visual C# .NET, an operation takes the following form:

Attributes Modifiers ReturnType Name(ParameterList)
{
}

Examples of Operations

The examples in Table 6.2 show attributes and their corresponding declarations in Visual C# .NET.

Table 6.2. Operations (Design) Versus Methods (Code)

UML Notation	Visual C# .NET Declaration
-InternalOpen()	private void InternalOpen()
#SetFirstName(firstName:string)	protected void SetFirstName (string firstName)
#GetLastName():string	protected string GetLastName()
+Open()	public void Open()

Classes

Looking at the real world, it is difficult to think of anything that cannot be represented as a class. Everywhere you look is an instance of a class. For example, a bird, a dog, a cat, a cow, and a person can all be modeled as a class. Each of them has a basic definition that all members of that class must share.

There are three main things that make up a class definition: attributes, operations, and constraints. As defined earlier, attributes are characteristics of a class or object; operations are actions that class or object can perform; and constraints are parameters to which the class or object must conform. For example, a dog can be represented as a class with certain attributes, such as legs, hair, mouth, and teeth. It can also have operations, such as walk and speak. Finally, it can also have a constraint, which states that if a person calls the dog, it must go to that person.

UML Notation for Classes

In UML, a class is depicted by a rectangle, as shown in Figure 6.3. An object has three compartments: name, attributes, and operations. The first compartment is for the object's name and stereotype. A stereotype is generally used to describe the use of a class. For example, you could create a class definition that serves as a storage container for a collection of objects. Depending on the intended implementation of that class, you could give that class a stereotype of <<container>> or <<collection>>.

Examples of Classes

Figure 6.4 shows the class definition for Door. It can be read as a Door has attributes of color, doorType (interior or exterior), and isClosed (opened or closed). In addition, the operations Open and Close can be performed.

Objects

An object is an instance of a class. However, it is easier to think of an object as a real-world thing, such as an apple, a person, a cow, and so on. An object contains state information that is defined in the class structure. For example, in the case of the Door class described in the class example, an object representation would be the actual door that you step through. It has a clearly defined state, such as brown, open, and exterior. An object knows which messages it receives have a corresponding operation and appropriately invokes that operation when received.

UML Notation for Objects

Similar to the class representation, an object is depicted by a rectangle, as shown in Figure 6.5. The rectangle contains either the name of the object or the name of the object and the corresponding class name. The name of the object usually begins with a lowercase letter and is underlined.

When attributes are displayed, the rectangle is divided into two separate compartments. They are displayed with the attribute name followed by a sample value or the value of that attribute in the current context. Because operations are not contextual, they are not shown in the object representation.

Examples

Figure 6.6 shows an instance of class Point named aPoint. It has two attributes: X and Y. In the current context, the values of X and Y are 200 and 100, respectively.

Object State Maintenance

Each object or instance of a class that has at least one attribute is said to have state. The state of an object is the value of the attributes of an object at any one time. For example, in the example presented in the "Objects" section, the state of the object aPoint is X=200 and Y=100.

State Notation

Because it is useful to model the state of an object only when it is necessary to perform some action based on the state of that object, state is generally not shown on design models. However, if you need to indicate the state of an object, there are two ways to do so. The first way is to use the object symbol, as in Figure 6.5, and show the attributes section along with the state values. The second way is to use a state diagram. Although a state diagram is useful, the creation of one is beyond the scope of this chapter.

Examples of State

In Figure 6.7, the state of the object jimmy is hair=red, height=6'0'', and position=prone.