Prefactoring

5.1. Categories and Classes

Sam came by and said, "Oh, by the way, the rental period is different based on the category of a CDRelease."

"What is a category?" I asked.

"Oh," he said nonchalantly, "it could be a Golden Oldie, New Release, or Regular. Didn't I mention that before?"

"You must have—I just didn't remember it," I noted dryly.

You can approach this issue in a couple of ways—using different classes and using different objects. Using different classes is often the solution for when a programmer learns about inheritance. Once you have a shiny new hammer, every problem is a nail needing to be pounded. But not every problem is, or should be, solved with inheritance. Often an extra attribute in a class will do the trick.

5.1.1. Different Classes

We have three different categories: NewRelease, GoldenOldie, and Regular. Because there are three names, a designer might make these three separate classes. Since they are CDReleases, a natural thing to do is to form an inheritance hierarchy with a base class from which to derive each class. Figure 5-1 shows what an inheritance-oriented class hierarchy might look like.

Figure 5-1. A CDRelease inheritance hierarchy

The CDRelease abstract base class defines the base_rental_period( )abstract method. This method is implemented differently for each type of CD. The base class and the three derived classes would look like those shown ...