Chapter 3. Object-Oriented Programming

The primary use of a class is to introduce a new type that more directly represents an entity in our application. In a library checkout application, for example, it is generally easier to program the classes Book, Borrower, and DueDate directly than to translate the program logic to the underlying character, arithmetic, and Boolean data types.

A programming model based on unrelated classes proves cumbersome when an application begins to be filled with class types that represent is-a-kind-of instances of another class type. For example, imagine that over time our library checkout application must add support for a RentalBook class, an AudioBook class, and an InteractiveBook class in addition to the original Book class. Each class is likely to share data members and the member functions to manage the data. Each class also will require additional unique data members to represent its state. Each class may (or may not) have a separate checkout and overdue fine algorithm, although each class will share the same interface.

The class mechanisms of the previous chapter cannot easily model both the commonality and the differences of these four are-a-kind-of Book classes. Why? The reason is that these mechanisms do not provide support for specifying relationships among classes. For this kind of support, we need the object-oriented programming model.