You know that strategy classes are easy to make and use. For example, you want to encapsulate your output formats in such a way that you can select the appropriate wrapper without affecting client code.
One of the nice aspects of this technique is that it is run-time dynamic: you can reassign (or re-bless, if the strategy classes don't differ by data) the strategy object ($output_strategy) at any time, to select a different strategy.package Output_Strategy::HTML; package Output_Strategy::CSV; . . . my $output_strategy = $opt{'html'} ? 'Output_Strategy::HTML' : 'Output_Strategy::CSV'; $output_strategy->preamble; $output_strategy->render(@data); $output_strategy->postamble; # whatever
Now, this technique makes the following assumption (or, more accurately, imposes the following constraint): the entity to be strategized (output format, in the example above) is a stand-alone class or object. It could even be a delegate within another object.
But, suppose you are extending the capabilities of a class via inheritance rather than delegation/composition. How can you apply a strategy pattern in the inheritance?
My answer is quite simple, and, again, it exploits Perl's highly dynamic nature. It involves modifying the inheritance tree at run time. And to make it more flexible, I insert a level of indirection in the inheritance chain, so that the "end user" classes don't need to be affected.
Suppose we have a set of classes (e.g. Foo) that want to "mix in" the methods of our output interface. Let Foo and Bar inherit from Output_Strategy; and let Output_Strategy inherit — based on a run-time setting — from one of the actual strategy classes.
And any time you need to change the strategy, you don't have to change the inheritance list (@ISA) of the "end user" classes (e.g. Foo).package Foo; use base 'Output_Strategy'; # this is a 'strategy handle class' . . . # set the inheritance path at run time: @Output_Strategy::ISA = ( $opt{'html'} ? 'Output_Strategy::HTML' : 'Output_Strategy::CSV' );
Note: I'm not saying this is better than delegation. I just think it's a potentially interesting alternative technique.
Glossary:
- Handle (sense 3): an indirect, or two-level, reference
- Strategy pattern
- Composition
- Delegation
- Facade pattern aka Wrapper
- Mix-ins
Update: I have referred to this "double-indirection" of classes as "handles" because the technique reminded me of the double-indirection of memory management, used in some operating systems. In Windows, these are called handles, and it makes sense; it's the same idea as file handles, and in fact (IIUC), Windows handles are an abstraction over all of the system resources a process can access. Wikipedia has an article on Handles, and it says a handle is "an abstract reference to a resource". But that doesn't really describe what I'm doing here, which is more accurately called a bridge. Wikipedia's article on Opaque pointers helpfully/confusingly refers to both handles and the Bridge pattern. :-)
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Strategy Handles
by diotalevi (Canon) on Jan 03, 2006 at 23:06 UTC | |
Re: Strategy Handles
by simon.proctor (Vicar) on Jan 04, 2006 at 13:42 UTC | |
by jdporter (Paladin) on Jan 04, 2006 at 19:50 UTC | |
by simon.proctor (Vicar) on Jan 05, 2006 at 09:42 UTC | |
Re: Strategy Handles
by Anonymous Monk on Jan 04, 2006 at 13:38 UTC | |
by jdporter (Paladin) on Jan 04, 2006 at 19:41 UTC | |
Re: Strategy Handles
by ruoso (Curate) on Jan 05, 2006 at 14:04 UTC | |
Re: Strategy Handles
by Anonymous Monk on Jan 04, 2006 at 13:36 UTC | |
by jdporter (Paladin) on Jan 04, 2006 at 19:56 UTC |