20.6. Association vs. Inheritance

Now you have seen two ways for a class to reuse code in another class. So, is one better than the other? When do you use inheritance, and when is association the better choice?

Although the subject of this chapter is inheritance, the truth is that association is usually a better choice than inheritance. Perhaps 95% of cases where you are debating about choosing inheritance or association, you should choose association. It’s hard to go wrong with association, but you can get into all kinds of trouble if you go with inheritance and inheritance is not an appropriate choice.

So, it’s easier to address the question of which technique to use by determining when inheritance is an appropriate choice. Inheritance is appropriate when the proposed child class (the one reusing the functionality in its parent) represents a specialization of its parent. You can test this by filling in the names of the child and parent class in the following sentence.

(child class) is a type of (parent class).

Let’s try an example. Using the LabeledPoint example from the previous section: “LabeledPoint is a type of Point.” Since a LabeledPoint is a specific type of Point–a point that has a label–that sentence makes sense. LabeledPoint is a specialization of Point, and inheritance is an appropriate choice. You can also use the substitution test. Inheritance is appropriate if a child object can substitute for a parent object. If I ask for a Point object and you give me a LabeledPoint object is that okay? Yes, they both are points.

Now, suppose you wanted to define a class that represents a rectangle. Like a Point, a Rectangle would need to keep track of an x and y location to determine its position, and might also have a width and a height. You’re thinking about defining Rectangle to inherit from Point, so that it reuses all of the functionality in Point (like knowing its position and calculating its distance from origin), and adding just the two new instance variables it needs for its width and height. From a pure code reuse standpoint, inheritance seems plausible. But wait–let’s apply the “is-a-type-of” linguistic test. Filling in the blanks in the sentence template above, we get: “Rectangle is a type of Point.” Most people would feel there is something wrong with that statement. A rectangle has a point, but is not itself a point. Thus, it fails the linguistic test; association is the better choice here. The test for association is also called a has-a relationship. You can test this by filling in the names of the two classes in the following sentence.

(class one) has a (class two).

So what happens if you decide to ignore the linguistic test and go ahead and make Rectangle inherit from Point? In some cases, you won’t run into trouble right away. Often, the difficulties don’t start to crop up until later, when you decide to add more methods to Point (the parent) that aren’t appropriate for Rectangle (the child). This leads to a program that is confusing to understand and contains bugs that occur when methods intended for Point are invoked on Rectangle instances by mistake. Also, since inheritance is the strongest form of relationship between classes, changes to code in a parent class have a stronger likelihood of breaking code in its children than would tend to occur if composition were used.

Inheritance is a powerful feature and, when used appropriately, a terrific way to reuse code. But, like most power tools, it can cut you up pretty badly if you don’t know what you are doing. Use it with caution and respect.

You have attempted of activities on this page