Strategy Handles

[jdporter]

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, if the strategy classes don't differ by data) 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 'strategy 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 (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. :-)

---