The Class Construct

---

The class sits at the root of all object-oriented thinking. When you declare a new class you are declaring a new data type from which objects can be created and used in a program. This is nothing new; you were exposed to structs and classes in chapter 10, and you’ve seen fundamental data types like char, int, and float used to create variables for use in programs as well.

What is new, however, is how you begin to think of classes and their relationship to other classes in a software system. In a complex software system, a class type, or several class types, will be declared and used to create one or more objects. An object in this sense is like a simple variable created from a fundamental data type; it could be intended to be used alone, but more than likely it is designed to be used in conjunction with other class type objects. Hence, a class type object is different from an object created from a fundamental data type because of the expanded role it can play in a software system. A class type object can send or receive messages to itself or to other class type objects, something ordinary objects created from fundamental data types cannot do.

Parts Of A Class Declaration

Example 11.1 shows the various parts of a typical class declaration.

Example 11.1: parts of a typical class declaration

The class declaration introduces a new data type. It begins with the class keyword followed by an identifier that forms the class name. I am not going to tell you how to name your classes, however, convention suggests that typographically they begin with a capital letter, and capitalize the first letter of each word that appears in the name. Grammatically, they should be singular noun names. Note the following examples:

Person Employee FuelPump RotorShaftSensor

The body of the class is that area between the opening and closing braces. In the body will appear any and all data member declarations and member function declarations. Convention suggests placing all public interface functions at the top of the class body. Since the default access to class members is private, this requires the use of the public access specifier. Class-wide constants can be, and usually are, given public access, and are placed along with the public interface functions under the public access specifier.

Protected functions are placed under the protected access specifier. The protected access specifier is used primarily to prevent horizontal access but allow vertical access to protected members by derived classes. In this sense it works exactly like the private access specifier from a horizontal access perspective.

Private data members and functions are placed under the private access specifier. Often times member functions are declared private as well as data members. I will show you why this is good design practice later in the section on access specifiers.

Under the public access specifier appear two special purpose function declarations. A constructor and a destructor. These functions are special for several reasons, but mainly, they have the same name as the class in which they appear. Constructors and destructors are covered in detail below.

Whatever you do, do not forget to put the semicolon after the closing brace of a class declaration. The compiler errors you get may be cryptic and it will be by dumb luck alone that, having exhausted every possible remedy to the problem, you decide to look to your class declaration one more time for relief. And then you notice, it is not there. You type the semicolon and compile, and a thousand compiler errors magically disappear. You have been warned, but the lesson will not have been learned until you make the mistake yourself.

A Minimum Class Declaration

Although example 11.1 shows a typical class declaration, the following line of code declares a complete class although it doesn’t do very much!

class Foo{};

Given this class declaration you could now use it to create Foo objects. The compiler will create both a default constructor and destructor, but, since there are no data members or member functions, the best you can do with Foo is create Foo objects and destroy them.

Place Class Declarations In Separate Header Files

Get into the habit of placing class declarations in header files. There should be only one class declaration per header file. Doing so makes finding a particular declaration easier than if you had placed several declarations in one header.

The UML Class Diagram

The UML representation for the class ClassName given in example 11.1 above is shown in figure 11-1 below:

Figure 11-1: UML Representation for the Class ClassName

UML classes are easy to draw and require no special software to create. You could use a pencil and paper to create them although if you plan on doing serious object-oriented analysis and design I recommend purchasing a good UML design tool such as Object Plant^™, Describe^™, or Rational Rose^™.

Referring to figure 11-1, a class is drawn as a rectangle with several compartments. The upper compartment contains the name of the class. The compartment below that contains the class’s attributes, and the one below that contains the class’s member functions. A minus sign in from of an attribute or member function name indicates private accessibility. A plus sign in front of an attribute or member function name indicates public accessibility.

The attribute named itsAttribute is declared to be of type integer as indicated by the keyword int following the colon to the right of its name. The constructor and destructor are declared to return no type as indicated by the lack of a return type to the right of their colons.

Class diagrams can be constructed from one or more UML classes. A class diagram pictorially represents the static relationship between classes in a software application. Figure 11-2 shows a class diagram for a simple navy fleet simulation application.

Figure 11-2: UML Class Diagram of a Simple Navy Fleet Simulation Application

The Concepts of State and Behavior

When designing object-oriented software you will think of objects as having state and behavior.

Object State

An object’s state is indicated by the value of its attributes at any given time during the object’s lifetime. Change an attribute’s value during an object’s lifetime and you change its state. Access to object attributes should be provided through class interface functions; object attributes should never be exposed for direct manipulation because they are considered an implementation detail.

Object Behavior

An object derives its behavior through the implementation of its class interface functions so it is a good idea to give class interface functions names that reflect the behavior they will produce when called.

---