In <[EMAIL PROTECTED]>, Daniel Santa
Cruz wrote:
> In the specific case of the Strategy pattern, I think the goal is to
> abstract out of the class an algorithm that can then be reused by some
> of the inherited classes. This way we don't repeat ourselves. Maybe I
> got this all wrong...
IMHO yes. The goal isn't to reuse the algorithm elsewhere but to plug in
different algorithms into the "main class", which is called `context` in
the GoF book.
> Abstract Base Class: Duck
> + FlyBehavior _fly
> + swim()
> + fly() -> calls _fly.fly()
>
> Interface: FlyBehavior
> + fly()
>
> Concrete Interface FlyHigh (implements FlyBehavior): + fly()
>
> Concrete Class Duck1 (Inherits Duck): + Constructor: _fly = new
> FlyHigh()
No need to make a subclass of `Duck` and the base class should not be
abstract but take a strategy in the constructor instead.
Silly, contrived example with ducks (the `context`):
class Duck(object):
def __init__(self, fly_strategy=lambda duck: None):
self._fly = fly_strategy
self.battery = 100.0 # Percent.
def fly(self):
self._fly(self)
A dumb strategy:
def flap_as_fast_as_you_can(duck):
duck.battery -= 5
And a more sophisticated one:
def ExploitThermodynamics(object):
def __init__(self):
# Initialize data structures to keep track of wind, target etc.
def __call__(self, duck):
# Check wind, update data and change the heading of the duck
# accordingly.
duck.battery -= used_power
Now some ducks:
no_fly_duck = Duck()
fast_but_soon_tired_duck = Duck(flap_as_fast_as_you_can)
gliding_duck = Duck(ExploitThermodynamics())
If the `strategy` is a callable one can decide if a simple function is
sufficient or if the `strategy` needs some state that must be preserved
between calls to the strategy object.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
