Re: Ensuring a method is overridden
markspace wrote:
Daniel Pitts wrote:
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.
That's interesting. The classic solution to "mixing and matching
behavior" is the Decorator Pattern. You have one decorator per
behavior, and you mix and match by adding the decorators that are
applicable. The advantage of decorators are that each class is a little
more insulated from changes in other classes, I think. The disadvantage
is that removing a behavior is more difficult (you have to unwind the
stack of decorators, and make a new stack, skipping the decorator you
want to remove).
I don't see how decorators are any more insulated than strategies.
Your strategy pattern idea seems to make replacing/removing a behavior
easier, but also (to me) seems to require a bit more complexity. Trade
off, I suppose, depending on which operation seems more important to
make easy and straightforward.
It requires minimal complexity, IMO, compared to decorators. Decorators
do have there uses, but they the pattern I'm describing solves a
different problem.
I would only use Decorators in to extend behavior (performing the same
behavior, but modifying the input and/or output of the extended behavior).
If you are only modifying one behavior (method) of an object that has
many behaviors, then it decorating it would lead to a lot of
"pass-through" behavior.
Using strategies instead allows you to group related methods in one
interface, and only requires you to implement the strategies you care
about changing. You can combine Decorators and Strategies as well, by
having a Strategy be Decorated.
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)
Decorators use composition too, just wanted to point that out.
Indeed they often do. However, in a different way than Strategy does.
The various strategy objects are composed in the model. Where as the
Decorators are composed of other Decorators or the Model object.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>