Avoid no-op overrides
| (3 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | :''It should be illegal for a derived class to override a base class method with a NOP method, i.e. a method which does nothing.'' --Riel's Heuristic 5.17, [[Arthur Riel 1996]] | |
| + | |||
| + | |||
| + | A no-op override is a method defined in a [[subclass]] with the express purpose of removing behaviour inherited from a [[superclass]]. | ||
"Don't do it" is what a no-op override is all about. What happens if you find that a class you are inheriting from provides a method with functionality that is inconvenient or unwanted? You might be tempted to remove that functionality by overriding the method with a blank method. | "Don't do it" is what a no-op override is all about. What happens if you find that a class you are inheriting from provides a method with functionality that is inconvenient or unwanted? You might be tempted to remove that functionality by overriding the method with a blank method. | ||
| Line 6: | Line 9: | ||
No-op overrides break the [[Liskov substitution principle]] and [[Design by contract]]. A class should be able to use any subclass of a particular object without having to worry about whether that object will still act in an appropriate manner. | No-op overrides break the [[Liskov substitution principle]] and [[Design by contract]]. A class should be able to use any subclass of a particular object without having to worry about whether that object will still act in an appropriate manner. | ||
| + | |||
| + | ==See also== | ||
| + | *[[Interface segregation principle]] | ||
| + | *[[Empty method over-rides]] | ||
| + | |||
| + | [[Category:Riel's heuristics]] | ||
Latest revision as of 22:48, 12 October 2009
- It should be illegal for a derived class to override a base class method with a NOP method, i.e. a method which does nothing. --Riel's Heuristic 5.17, Arthur Riel 1996
A no-op override is a method defined in a subclass with the express purpose of removing behaviour inherited from a superclass.
"Don't do it" is what a no-op override is all about. What happens if you find that a class you are inheriting from provides a method with functionality that is inconvenient or unwanted? You might be tempted to remove that functionality by overriding the method with a blank method.
If you find yourself in this situation there are other things you should look at first. Inheritance is about Is-a relationships. This means that if your class Rabbit Is-a(n) Animal it can do all the things an animal can do. If you are inheriting functionality that is not wanted then you must ask are you inheriting from the right class.
No-op overrides break the Liskov substitution principle and Design by contract. A class should be able to use any subclass of a particular object without having to worry about whether that object will still act in an appropriate manner.
