Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Strategy Handles

by jdporter (Canon)
on Jan 03, 2006 at 21:47 UTC ( #520738=perlmeditation: print w/ replies, xml ) Need Help??

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 '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:


We're building the house of the future together.

Comment on Strategy Handles
Select or Download Code
Re: Strategy Handles
by diotalevi (Canon) on Jan 03, 2006 at 23:06 UTC

    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.

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

Re: Strategy Handles
by Anonymous Monk on Jan 04, 2006 at 13:36 UTC
    Objects are not handles, no need for glossary, just call it what it is.
      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.

      We're building the house of the future together.
Re: Strategy Handles
by Anonymous Monk on Jan 04, 2006 at 13:38 UTC
    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.
      Instead of re-blessing, you should ...

      I never said one should rebless. My meditation illustrates a technique using inheritance tree twiddling, not reblessing. But TIMTWOTDI. I mentioned re-blessing parenthetically because it's another way to achieve the same result, and might be preferable for some people or in some circumstances.

      What you call strategy is the View in Module-View-Controller pattern.

      Only in the example I gave. Strategies can be used anywhere in an architecture.

      We're building the house of the future together.
Re: Strategy Handles
by simon.proctor (Vicar) on Jan 04, 2006 at 13:42 UTC
    Surely changing inheritence on the fly is against the idea of the OO patterns in the first place? 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 would be interested in seeing arguments to say that it is.

    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 considering 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. :-)

      We're building the house of the future together.
        > But the fact that it is all about inheritance of methods,

        Yeah thats true but it is quite evil. And in a monestary too ;).
Re: Strategy Handles
by ruoso (Curate) on Jan 05, 2006 at 14:04 UTC

    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.

    daniel

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://520738]
Approved by atcroft
Front-paged by kutsu
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (14)
As of 2014-12-18 20:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (61 votes), past polls