Empty method over-rides
| Line 13: | Line 13: | ||
* Allow empty method overrides | * 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. | * 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. This | + | * 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. | ||
Revision as of 21:17, 1 August 2009
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.
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.
