A class defines the state and behavior of objects. In C++, member variables hold state, member functions determine behavior, and runtime code instantiates objects from the class. Public members form the interface; private and protected members restrict access and support encapsulation. section 1.8
Use classes to give an application’s concepts explicit structure:
- Represent state with member variables whose values change during execution. section 1.8
- Define behavior with member functions that operate on that state. section 1.8
- Control change through public interfaces and private or protected implementation details. section 1.8
- Support inheritance by allowing subclasses to reuse, extend, or override state and behavior. section 1.8
From library requirements to classes
Suppose requirements describe a book catalogue. Textual analysis identifies nouns such as catalogue, book, attribute, librarian, customer, title, and year. These nouns are candidates, not automatic classes: catalogue, book, attribute, and form become initial classes, while librarian and customer remain external agents and title and year remain attribute values. Iterative design then assigns state, such as a catalogue’s book list, a book’s attributes, and a form’s input values. section 3.9.1
Class design begins with requirements but does not end there. Prototypes and development iterations can add or refine classes, while design documentation records the evolving structure. Requirements may change, so the class model should develop iteratively. section 4.1 section 1.5
Table 3.1 Decide whether each noun of the requirements should be a class. (view table figure)
| Noun |
Class? |
|---|---|
| catalogue |
Yes. The application implements a book catalogue. |
| Book |
Yes. The catalogue stores book objects. |
| attribute |
Yes. Each book object has a set of attributes. |
| librarian |
No. According to figure 3.4, a librarian is an agent outside of the application. |
| customer |
No. According to figure 3.4, a customer is an agent outside of the application. |
| kind |
No. It is an attribute value that is an enumeration constant. |
| title |
No. It is an attribute value that is a string. |
| name |
No. It is an attribute value that is a string. |
| year |
No. It is an attribute value that is an integer. |
| genre |
No. It is an attribute value that is an enumeration constant. |
| region |
No. It is an attribute value that is an enumeration constant. |
| subject |
No. It is an attribute value that is an enumeration constant. |
| browser |
No. The application works with existing browsers. |
| form |
Yes. The application manages a user input form. |
| input |
No. It is an attribute value entered by a user into a form. |
| format |
No. A format isn’t a separate thing in the application. |
| value |
No. An attribute value is an integer, string, or enumeration constant. |
| string |
No. The application uses built-in C++ strings. |
Compare requirements nouns with the decisions that make them classes, external agents, or attribute values. section 3.9.1
