9.1. Classes And Objects

Rumbaugh et al.¹ succinctly summarize two ways that the object-oriented paradigm benefits software development:

Object-oriented modeling and design is a way of thinking about problems using models organized around real-world concepts. The fundamental construct is the object, which combines both data structure and behavior in a single entity (p. 1).

Software developers view problems through an object-oriented lens, matching the problem's real-world components to corresponding programming features characterized with object-oriented terminology. Object-orientation is both a way of approaching problems and of implementing their solutions, with objects serving as the fundamental construct. Today, object-oriented practitioners typically refer to the data structure and behavior as attributes and operations, respectively.

Object-orientation forms a bridge that spans the entire software development process, joining analysis, design, and programming. Unlike earlier software development processes that suffered paradigm shifts (abrupt changes in how developers represent the problem) between phases, object-orientation maintains a consistent object-based vocabulary throughout the development process.

The object-oriented paradigm encompasses three essential concepts: encapsulation, inheritance, and polymorphism. The textbook presents inheritance and polymorphism in subsequent chapters. However, encapsulation is the hallmark of objects and the ideal place to begin.

Encapsulation

Encapsulation combines attributes and operations (Rumbaugh's data structure and behavior) into an entity that computer scientists refer to as an object. Objects isolate and protect their data, blocking direct access by functions and other objects, allowing indirect access or use only through their operations. All the object's operations can use or modify its attributes, forming an intermediate scope between local and global. The intermediate scope allows limited, identifiable function coupling while preventing it from becoming difficult to locate and manage.

A class can describe many objects having the same attributes and operations. A common metaphor is to think of a class as a cookie-cutter and the individual objects as the cookies. The cookie cutter defines the size, shape, and decoration of each cookie. We can use the cookie cutter to stamp out as many cookies as we want, and each cookie will have the same size, shape, and decorations as the others. However, we eat the cookies, but not the cookie cutter; similarly, objects, not classes, do the work in a program. C++ programmers call attributes and operations member³ variables and functions, respectively. Like all variables, member variables have a type and a name. Similarly, member functions have a name, a parameter list (which may be empty), and (except for constructor and destructor functions) a return type. Rumbaugh et al.¹ collectively refer to attributes and operations as features, a practice the text continues.

Attributes

Attributes are the values saved in an object. Ideally, each attribute is a quality or characteristic inherent in the entity the class represents - some aspect whose value helps distinguish between different instances or objects of the class.

Operations

Operations represent the services an object can provide to an object-oriented client or application program. Recall that C++ is a hybrid language, meaning it supports "regular" functions, unrelated to classes, and functions that are class members. In C++, class member functions correspond to object-oriented operations. Most member functions follow the same syntax used in the preceding chapters: they have a header (the return value type, the function name, and the argument list) and a body.

Class Responsibilities

Ward Cunningham (Fowler⁴, pp. 62-63) introduced class-responsibility-collaboration (CRC) cards in the early days of industrial object-oriented software development. CRC cards consist of physical index cards on which developers write the name of a class, its responsibilities, and the names of other classes with which it collaborates. Rearranging the cards while discussing various ways a program can use the class helps developers determine which class to make responsible for maintaining various data items and providing the services a program needs to solve a given problem. The determination is relatively simple when a program uses few classes, but it becomes more challenging as the number of classes and their collaborations increase. For example, imagine two classes: Contractor and Project. Furthermore, imagine that the application tracks the contractor's pay rate and the number of hours worked. Which is responsible for maintaining the data? It's possible to create scenarios favoring each choice, and the text returns to this problem in a subsequent chapter, presenting various implementation options.

Feature Visibility

C++, like Java, controls the visibility of class features with a set of keywords (in order of increasing visibility): private, protected, and public. Although the C++ syntax is a little different than Java, the meanings of the keywords are the same in both languages, as summarized by the following Venn diagram.

C++ Class Specifications

C++ classes differ in two important ways from Java classes. First is the obvious difference in how they use the public and private (and later the protected) keywords. The features in a Java class are individually declared as public or private. Alternatively, in a C++ program, regions within the classes are labeled as public or private. Second, Java always includes method bodies inside the class. C++ programs can define short member functions inside of a class (and doing so makes them inline functions, without the need to use the inline keyword), but programmers should only prototype larger functions in the class and write the bodies in a separate compilation unit (i.e., another .cpp file). For example:

class Time
{
	private:
		int	hours;
		int	minutes;
		int	seconds;

	public:
		Time();
		Time(int h, int m, int s);
		Time(int s);

		Time	add(Time t2);
		Time*	add(Time* t2);

		void	print();
		void	read();
};

Class And Object Summary

Although the above class is a simple example, there are several important observations we can make:

• Notice that a C++ class, like a C++ struct, is terminated with a semicolon. The only difference between a struct and a class is the default visibility: structures have public visibility, and classes have private visibility. Nevertheless, C++ programmers generally only use structures to represent packaged data and reserve classes for truly object-oriented situations (i.e., when an entity should have attributes and operations packaged together).
• The public and private sections can appear in any order (I'll explain in the next section why I typically put my private section first and my public section second). Furthermore, a class may have any number of public and private sections in any order. Any features labeled with the private keyword will have private visibility until another label changes it; similarly, any features labeled with the public keyword will have public visibility until another label changes it.
• In this example, only function prototypes are included in the class. Programmers frequently specify a single class in a header (i.e., .h) file named after the contained class and write the complete functions (including their bodies) in a separate .cpp file, also named for the class. Organizing classes this way makes them easier to reuse. This organization is the same as introduced with structs in chapters 5 and 6.
• Like a struct, the name of a class becomes a type specifier, meaning it is a new, programmer-created data type. The class name may appear wherever a program requires the name of a data type, specifically in a variable definition statement:

  Time start;
  Time* end = new Time;

  In this context, we can also call start and end objects (which implies that an object is just a variable created from a class or structure). When we create a new object as illustrated above, we are said to have instantiated the class, so an instance is a synonym for an object.
• We can use a ZIP file to help understand the behavior of objects and the relationship between an object and its member variables. A ZIP file is a container that holds other files. However, it's also a single file that we can move, copy, and store like any other computer file. Similarly, an object is a single, named data item (i.e., a variable) that we can move, copy, and store like any data item. However, an object is also a container that holds other data called member data or member variables. The assignment operation is essential:

  Time temp = start;
  

  copies start, byte-by-byte, to the new object temp. This example oversimplifies object assignment, but later chapters revisit the operation, clarifying it and adding detail.
• Notice that three of the function prototypes (add, print, and read) are "normal" function headers with a return value type, function name, and argument list, but the first three prototypes do not have a return value type. The first three functions are constructors. Programs call constructor functions automatically when instantiating new objects (e.g., start above) to "construct" or initialize the object. When a constructor function has an empty parameter list, the C++ syntax still requires the parentheses in the prototype (as seen in the class specification above) and the definition. But unlike Java, when calling a constructor (e.g., the instantiation of start above), the parentheses are optional (in the past, they were not allowed). Parentheses are required when a constructor call passes arguments to the function. Constructor functions have another distinguishing characteristic: the function's name is the same as the class name. (Remember that C++ is a case-sensitive language, so Time is not the same as time). The example above suggests that constructors, like other functions, can be overloaded. We'll study constructors in greater detail in a later subsection.
• Finally, the dot operator is used in C++, just as in Java, to access member variables and functions inside an object. Additionally, it is possible to have a pointer to an object; in this case, the arrow operator selects variables and functions in the object. Ignoring visibility issues (i.e., private features) for a moment, and assuming appropriately defined functions, the features of an object may be accessed as illustrated:

  Time start; Time end; start.hours = 60; cout << start.minutes << out; end.read(); Time total = start.add(end); total.print();	Time* start = new Time; Time* end = new Time; start->hours = 60; cout << start->minutes << out; end->read(); Time* total = start->add(end); total->print();
  (a)	(b)

1. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W. (1991). Object-Oriented Modeling and Design. Englewood Cliffs, NJ: Prentice Hall.
2. Wirfs-Brock, R.; Wilkerson, B. (1989). "Object-oriented design: a responsibility-driven approach." Conference Proceedings on Object-Oriented Programming Systems, Languages and Applications. OOPSLA 1989 Proceedings, October 1-6.
3. You may see some variation in terminology between different authors. Historically, authors called the variables declared inside a class either a member or a static variable (covered in detail later in the chapter). Alternatively, some authors refer to all variables declared inside a class as member variables and further categorize them as either instance variables or class variables (also detailed later). I learned and used the first terminology as a professional software engineer. Furthermore, static or class variables are uncommon. Consequently, I use the first terminology throughout the text but explicitly state when I'm discussing static or class variables. The variations also apply to functions, although less commonly.
4. Fowler, M. (2004). UML distilled: A brief guide to the standard object modeling language. Boston: Addison-Wesley.