Cedric has some good comments about the "call super antipattern". For background, some designs require that a method m() on a class C call-back to the super at either the top of bottom of the subclass method:
class SubC extends C {
void m() {
// do some stuff
// and then don't forget to call the super
super.m();
}
This might seem like a small incremental sin after using extends in the first place, but call super is insidious because it's like a secret handshake. As that software ages, someone will add code or extend the module and forget about calling super, causing all hell to break loose in some subtle way. Even worse, someone may alter the base class without knowing about the dependencies. (Extension is often used as a substitute for a macro facility in Java, but that's another topic.)
The call super antipattern is an example of favoring recursion over iteration because the class extension mechanism for Java classes makes it convenient. Any number of the usual techniques for replacing recursion with iteration (remember Towers of Hanoi from CS 101?) can be used to unravel a design that uses the call super antipattern and will make for a better design now and down the road.
Add a comment.
