Chapter 5. Object-Oriented Programming

As you saw in Chapter 4, the primary use of a class is to introduce a new type that more directly represents an entity in our application domain. In a library check-out 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.

The object-based programming model proves cumbersome when our application begins to be filled with class types that represent an is-a-kind-of instance of a type. For example, imagine that over time our library check-out 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 requires additional unique data members to represent its state. Each class may (or may not) have a separate check-out and overdue fine algorithm, although each class shares the same interface.

The object-based class mechanisms of Chapter 4 cannot easily model both the commonality and the differences of these four are-a-kind-of Book classes. Why? It's because this model does not provide support for specifying relationships among classes. For this kind of support, we need the object-oriented programming model.