O'Reilly logo

Prefactoring by Ken Pugh

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

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 ...

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required