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.
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
One of the nice aspects of this technique is that it is run-time dynamic:
you can reassign (or re-bless) the strategy object ($output_strategy)
at any time, to select a different strategy.
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.
package Foo;
use base 'Output_Strategy'; # this is a 'strrategy handle class'
. . .
# set the inheritance path at run time:
@Output_Strategy::ISA = ( $opt{'html'}
? 'Output_Strategy::HTML'
: 'Output_Strategy::CSV' );
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).
Note: I'm not saying this is better than delegation. I just think it's a potentially interesting alternative technique.
Glossary:
- Handle: an indirect, or two-level, reference
- Strategy pattern
- Composition
- Delegation
- Facade pattern aka Wrapper
- MixIn
It should be noted that the method cache is invalidated anytime any @ISA changes, anywhere. This trick wouldn't even work if it weren't the case.
⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊
Objects are not handles
Right, and I didn't say they were. A "handle" (in this sense) is a "reference to a reference", or a "double-indirect reference". In the technique I propose, the references are actually symbolic references, because they're names — specifically, class names.
no need for glossary
You may not have needed it; I provided it as a convenience for those who aren't as clueful as you.
One of the nice aspects of this technique is that it is run-time dynamic: you can reassign (or re-bless) the strategy object ($output_strategy) at any time, to select a different strategy.Instead of re-blessing, you should use a different strategy object. What you call strategy is the View in Module-View-Controller pattern.
... you should ...
TIMTWOTDI. But I never said one should rebless; and in fact the point my meditation is not about reblessing at all, it's about twiddling the inheritance tree.
I have my own arguments against this:
By changing the inheritence dynamically (assuming, of course, that it were possible in any language) you are replicating the same process as interfaces (well sort of). So why muck with the chain (which can have interesting side effects) when the principle of the strategy pattern is to load objects capable of completing the responsibilities of the task via the interface required. The contract is between the calling code and the interface and you assume that it will do what you want. By working on the problem via changing inheritence you are circumnavigating that contract. Ok if you are a sole programmer. Not ok if you are working in a team (or across companies). Its certainly frought with problems.
If this were available I think I would be pretty safe in saying that I would never make use of it.
But that is my 2p. Please take with a pinch of salt :)
S
If you need to change what output you provide by dynamically changing inheritence then I don't see how you can say this alternate technique is OO based.
I'm not into making rigorous definitions of OO, nor am I arguing that this technique is or isn't OO in any kind of purist sense. But the fact that it is all about inheritance of methods, I don't know what other drawer to file it under. Remember that Perl's OO is not (much) like any other language's OO. One of the ways in which it's different comes from the highly dynamic nature of the language itself. And this technique is merely an example of that.
If this were available I think I would be pretty safe in saying that I would never make use of it.
It is available. And no, I don't actually expect anyone to make use of it. :-)
Mentioning Design Patterns, The pattern I use for this type of problem is "Class Factory". Using this pattern you won't need that each implementation are subclasses or not of the Interface (Well, actually you have several classes that implements the same interface).
The class factory could, for instance, check a configuration file, the time of the day and the phase of the moon to decide which implementation to use and this would be hidden from the code that uses it.