Empty method over-rides
m (Reverted edits by Ebybymic (Talk); changed back to last version by Lukas Korsika) |
|||
| (9 intermediate revisions by 4 users not shown) | |||
| Line 4: | Line 4: | ||
[[Image:Empty-method-override.png]] | [[Image:Empty-method-override.png]] | ||
| + | |||
| + | * The Dog class has a basic bark() method. | ||
| + | * This has been overridden to give slightly different behavior in the LoudDog and QuietDog classes. | ||
| + | * QuietDogs don't bark at all, so the QuietDog.bark() method is empty. | ||
| + | |||
| + | == Possible Solutions == | ||
| + | |||
| + | * Allow empty method overrides | ||
| + | * Allow empty method overrides, but the empty method should throw an exception. In many cases this would require the use of the instanceof operator. This destroys polymorphism. | ||
| + | * Extend the hierarchy. Break the interface up so that empty method overrides are not necessary (see below). | ||
| + | |||
| + | == The Real Solution (?) == | ||
| + | |||
| + | [[Image:Empty-method-override-sol.png]] | ||
| + | |||
| + | The above solution recognizes that not all Dogs bark(). This was the fundamental flaw in the previous design. This solution may seem less desirable because if you have a collection of Dogs you can no longer iterate through them all and tell them to bark(). However, if this is what you are trying to do you may need to reconsider how you organise your collections. One solution may be to have a collection of BarkingDogs, and another of QuietDogs. If this distinction is meaningful in real life it should be reflected in your code. | ||
| + | |||
| + | Another possible solution would be to have a tryBark method which returns whether any actual barking occurred. This way, you could store a list of dogs, and try to make all of them bark. Of course, this loosens the post-conditions of the bark() method, but in this case it's probably a more accurate representation of [[Model the real world|the real world]]. | ||
| + | |||
| + | == See Also == | ||
| + | * [[Avoid no-op overrides]] | ||
| + | * [[Refused bequest smell]] | ||
Latest revision as of 03:17, 25 November 2010
Empty method overrides occur when some part of an interface is not relevant to some specific implementation. This can occur when implementing interfaces or inheriting from some class. In this situation it is tempting to override the method with an empty implementation which does nothing. Often the goal is to maintain polymorphism despite the fact that it would seem the interface doesn't fit well.
Contents |
Example
- The Dog class has a basic bark() method.
- This has been overridden to give slightly different behavior in the LoudDog and QuietDog classes.
- QuietDogs don't bark at all, so the QuietDog.bark() method is empty.
Possible Solutions
- Allow empty method overrides
- Allow empty method overrides, but the empty method should throw an exception. In many cases this would require the use of the instanceof operator. This destroys polymorphism.
- Extend the hierarchy. Break the interface up so that empty method overrides are not necessary (see below).
The Real Solution (?)
The above solution recognizes that not all Dogs bark(). This was the fundamental flaw in the previous design. This solution may seem less desirable because if you have a collection of Dogs you can no longer iterate through them all and tell them to bark(). However, if this is what you are trying to do you may need to reconsider how you organise your collections. One solution may be to have a collection of BarkingDogs, and another of QuietDogs. If this distinction is meaningful in real life it should be reflected in your code.
Another possible solution would be to have a tryBark method which returns whether any actual barking occurred. This way, you could store a list of dogs, and try to make all of them bark. Of course, this loosens the post-conditions of the bark() method, but in this case it's probably a more accurate representation of the real world.
