Re: Ensuring a method is overridden
Lew wrote:
Mike Amling wrote:
I presume you recommend some kind of
proxy to ensure toString, equals, hashCode, etc. are overridden:
abstract class Basso {
protected abstract String abString();
public final String toString() {
return abString();
}
}
final class Extenso extends Basso {
public String abString() {
return "whatever";
}
}
That's sort of a strange suite of methods to require overriding. It's
already best practice to override toString, hashCode and equals,
though not "etc.". (What other methods of Object do you contemplate
overriding? Not much else makes sense to override.)
The pattern you show is a common one - define an abstract base class
with a public method that invokes abstract helper methods so that
subclasses can provide the varying parts. Often the abstract methods
are protected rather than public, since it's the wrapping method
(toString in your example) that you want client code to use, not the
helper method (abString).
Yet another approach is to move those methods out of the class
altogether, and use the Strategy pattern. This is my favored approach
if there are a lot (read "more than one") of the "methods" that would
need to be customizable, but mixing and matching the behaviors would
make sense.
This is kind of the upside down version of "Prefer Composition over
Inheritance". You're still preferring Composition over Inheritance, but
the main entity doing the preferring is what would have been the Base
Class (rather than the Derived Class)
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>