Re: Call-Super antipattern
On Wed, 7 May 2008, Philipp wrote:
Daniel Pitts wrote:
Philipp wrote:
I just read about the "Call-Super" antipattern
(http://en.wikipedia.org/wiki/Call_super) and I'm not completely convinced
about the "anti-pattern" property of this construct.
Despite that, a framework should rely as little as possible on consumers to
"do the right thing". The right way to do it is to have an protected
overridable method that isn't expected to call super, and the
non-overridable public method that delegates to the appropriate.
In other words, the work-flow should be defined by the class higher in the
hierarchy, and the details by the lower.
While I understand and agree with the above, this does not exactly solve my
problem (or it is not clear to me how). The point is, that all classes in the
hierarchy are instantiable and all should be startable using the start()
method.
So making start() call a hook() method in the top class, which can be
overriden is only solving the problem for the first child level. For the
grand-child, the question remains: should grandChild.hook() call
child.hook() or should we make child.hook() call anotherHook(), which
can then be overriden by the grand-child class.
Clearly, what Java needs is a sub keyword. Like super, but it goes the
other way.
Uh, thinking about it, maybe not.
But a language feature which means something like "when you send this
message to an object, invoke all the matching methods in the hierarchy,
not just the most-overriding one" would do it. I'm not aware of any
language having a feature like that; i think you could get the effect in
python using a metaclass, and you could probably do the same in any other
language that supports deep metamagic, like LISP, but nothing lets you do
it directly.
One of my rules of thumb is to look for ways to replace inheritance with
composition. So, how about this, using a pumped-up version of the Type
Object pattern (or is it really Strategy?):
/* our sort-of Type Object */
public abstract class VehicleType {
public final VehicleType base ; // used to mimic inheritance hierarchy
protected VehicleType(VehicleType base) {
this.base = base ;
}
// sort-of Template Method pattern here
public void start() {
handleStart() ;
if (base != null) base.start() ;
}
public abstract void handleStart() ;
}
/* the instances of the Type Object - which are actually singletons of
different classes, defined as anonymous classes */
public static final VehicleType VEHICLE = new VehicleType (null) {
public void handleStart() {
unlockDoors() ;
}
} ;
public static final VehicleType CAR = new VehicleType (VEHICLE) {
public void handleStart() {
startEngine() ;
}
} ;
public static final VehicleType FORD = new VehicleType (CAR) {
public void handleStart() {
switchRadioOn() ;
}
} ;
/* our vehicle class */
public class Vehicle {
public final VehicleType type ;
public Vehicle(VehicleType type) {
this.type = type ;
}
public void start() {
type.start() ;
}
}
(note that i haven't tried to compile this, so please excuse any syntax
errors; i hope the intent is clear)
Is this icky?
In reality, you'd want VehicleType.start to take a Vehicle as a
pseudo-this parameter, so it can operate on the vehicle being started.
A problem arises when you want to have more than just start() - maybe
stop(), accelerate(), brake(), etc, since then the template methods in
VehicleType all have to include the boilerplate to walk the type object
hierarchy, which means duplication of code. If we had higher-order
functions, the walking could easily be refactored, but we don't. Thus,
we'd have to use a bit of Visitor pattern:
/* a visitor type, of sorts */
public abstract class VehicleAction
{
public abstract void apply(VehicleType type) ;
}
/* modified Type Object with a visitation method */
public abstract class VehicleType {
public final VehicleType base ; // used to mimic inheritance hierarchy
protected VehicleType(VehicleType base) {
this.base = base ;
}
// sort-of Template Method using the sort-of Visitor
public void do(VehicleAction action) {
action.apply(this) ;
if (base != null) base.do(action) ;
}
public abstract void handleStart() ;
public abstract void handleStop() ;
}
/* concrete visitors, again as singleton instances of anonymous classes */
public static final VehicleAction START = new VehicleAction() {
public abstract void apply(VehicleType type) {
type.handleStart() ;
}
}
public static final VehicleAction STOP = new VehicleAction() {
public abstract void apply(VehicleType type) {
type.handleStop() ;
}
}
/* aaand finally ... */
public class Vehicle {
public final VehicleType type ;
public Vehicle(VehicleType type) {
this.type = type ;
}
public void start() {
type.do(START) ;
}
public void stop() {
type.do(STOP) ;
}
}
This is the kind of thing that gives OOP a bad name, isn't it?
tom
--
Ensure a star-man is never constructed!