Classes

A class is an abstraction describing the common features of all objects in a group of similar objects. For example, a class called "Student" could be created to describe all student objects recognized by the Student Registration System.

A class defines the following:

The data structure (names and types of attributes) needed to define an object belonging to that class
The operations to be performed by such objects: specifically, what these operations are, how an object belonging to that class is formally called upon to perform them, and what "behind the scenes" things an object has to do to actually carry them out

For example, the Student class might be defined to have the nine attributes described in Table 3-1.

Table 3-1: Proposed Attributes of the Student Class
Attribute	Type
`name`	`string`
`studentId`	`string`
`birthdate`	`DateTime`
`address`	`string`
`major`	`string`
`gpa`	`double`
`advisor`	???
`courseLoad`	???
`transcript`	???

This means each and every Student object will have these same nine attributes. Note that many of the attributes can be represented by predefined C# types (e.g., string, double, and DateTime) but that a few of the attributes—advisor, courseLoad, and transcript—are too complex for predefined types to handle; you'll learn how to tackle such attributes a bit later on.

In terms of operations, the Student class might define five methods as follows:

RegisterForCourse
DropCourse
ChooseMajor
ChangeAdvisor
PrintTranscript

Note that an object can only do those things for which methods have been defined by the object's class. In that respect, an object is like an appliance: it can do whatever it was designed to do (a DVD player provides buttons to play, pause, stop, and seek a particular movie scene), and nothing more (you can't ask a DVD to toast a bagel—at least not with much chance of success!). So, an important aspect of successfully designing an object is making sure to anticipate all of the behaviors it will need to be able to perform in order to carry out its "mission" within the system. We'll see how to determine what an object's mission, data structure, and behaviors should be, based on the requirements for a system, in Part Two of the book.

Note?/td>

The terms feature and member are used interchangeably to refer to both attributes and methods of a class. That is, a class definition that includes three attribute declarations and five method declarations is said to have eight features/members. "Feature" is the generic OO term, "member" the C#-specific term.We'll use generic OO terminology in Parts One and Two of the book, switching to C#-specific terminology in Part Three.

Features are the building blocks of a class: virtually everything found within a class definition is either an attribute or a method of the class.

Note?/td>

In the C# language, several other types of things are included within the boundaries—i.e., are features—of a class definition, but we won't worry about these until we get to Part Three of the book. Conceptually, it's sufficient to think of an object as consisting only of attributes and methods at this point in time.

A Note Regarding Naming Conventions

It's recommended practice to name classes starting with an uppercase letter, but to use mixed case for the name overall: Student, Course, Professor, and so on. When the name of a class would ideally be stated as a multiword phrase, such as "course catalog", start each word with a capital letter, and concatenate the words without using spaces, dashes, or underscores to separate them: for example, CourseCatalog. This style is known as Pascal casing.

For method names, the C# convention is to use Pascal casing as well. Typical method names might thus be Main, GetName, or RegisterForCourse.

In contrast, the C# convention for attribute names is to start with a lowercase letter, but to capitalize the first letter of any subsequent words in the attribute name. Typical attribute names might thus be name, studentId, or courseLoad. This style is known as Camel casing.

In subsequent chapters, we'll refine the rules for how Pascal and Camel casing are to be applied.

Instantiation

A class definition may be thought of as a template for creating software objects—a "pattern" used to

Stamp out a prescribed data area in memory to house the attributes of a new object.
Associate a certain set of behaviors with that object.

The term instantiation is used to refer to the process by which an object is created (constructed) based upon a class definition. From a single class definition—for example, Student—we can create many objects, in the same way that we use a single cookie cutter to make many cookies. Another way to refer to an object, then, is as an instance of a particular class—e.g., a Student object is an instance of the Student class. We'll talk about the physical process of instantiating objects as it occurs in C# in a bit more detail later in this chapter.

Classes may be differentiated from objects, then, as follows:

A class defines the features—attributes, methods, etc.—that all objects belonging to the class possess, and can be thought of as serving as an object template, as illustrated in Figure 3-1.

Figure 3-1: A class defines attribute names and types.
An object, on the other hand, is a unique instance of a filled-in template for which attribute values have been provided, and on which methods may be called, as illustrated in Figure 3-2.

Figure 3-2: An object provides attribute values.

Encapsulation

Encapsulation is a formal term referring to the mechanism that bundles together the state and behavior of an object into a single logical unit. Everything that we need to know about a given student is, in theory, contained within the "walls" of the student object, either directly as a field of that object or indirectly as a method that can answer a question or make a determination about the object's state.

Note?/td>

Encapsulation isn't unique to OO languages, but in some senses is perfected by them. For those of you familiar with C, you know that a C struct(ure) encapsulates data:

  struct employee {
      char name[30];
      int age;
  }

and a C function encapsulates logic—data is passed in, operated on, and an answer is optionally returned:

  float average(float x, float y) {
      return (x + y)/2.0;
  }

But only with OO programming languages is the notion of encapsulating data and behavior in a single construct, to represent an abstraction of a real-world entity, truly embraced.