P.71.REfactoring.pdf重构

拒绝遗赠

Subclasses get to inherit the methods and data of their parents. But what if they don't want or
need what they are given? They are given all these great gifts and pick just a few to play with.
The traditional story is that this means the hierarchy is wrong. You need to create a new sibling
class and use Push Down Method and Push Down Field to push all the unused methods to
the sibling. That way the parent holds only what is common. Often you'll hear advice that all
superclasses should be abstract.
You'll guess from our snide use of traditional that we aren't going to advise this, at least not all the
time. We do subclassing to reuse a bit of behavior all the time, and we find it a perfectly good way
of doing business. There is a smell, we can't deny it, but usually it isn't a strong smell. So we say
that if the refused bequest is causing confusion and problems, follow the traditional advice.
However, don't feel you have to do it all the time. Nine times out of ten this smell is too faint to be
worth cleaning.
The smell of refused bequest is much stronger if the subclass is reusing behavior but does not
want to support the interface of the superclass. We don't mind refusing implementations, but
refusing interface gets us on our high horses. In this case, however, don't fiddle with the
hierarchy; you want to gut it by applying Replace Inheritance with Delegation.