2

I've got a Python project wherein a basic object is created and various different attributes are modified/given to it via what I thought was a good example of a strategy pattern.

In this silly game there are enemies with multiple different potential patterns of movement. The Enemy class has a basic pattern of movement it defaults to; otherwise, a strategy pattern is implemented to randomly choose different ones as the game progresses.

The Enemy's obj.update() is something like this:

def update(self):
    self.unique_action()
    self.check_if_shooting()
    self.find_new_rect()

So I'd been replacing self.unique_action on the fly with a strategy pattern using what I think are called 'higher-order functions'.

def new_pattern_of_movement(obj, func):
    def inner(*args, **kwargs):
        ##code for doing different stuff
        ##intentionally NOT returning the function - 
        ##the idea is to replace the default unique_action
    return inner

…
##eventually when generating bad guys for the level…
newEnemy = Enemy()
new_AI = random.choice([new_pattern_of_movement, other_pattern, some_other_pattern]) #etc etc
newEnemy.unique_action = new_AI(newEnemy, newEnemy.unique_action)

After a while, I thought, "self, why not change their attributes as part of the wrapper as well? you change their methods, just set their point_value and graphics and all that dumb stuff too" and I was like "welp I can do that"

def alt_action(obj):
    def inner(*args, **kwargs):
        ##code for their unique_action
        ##again, not returning obj.unique_action
    obj.point_value += 100
    obj.color = colors.YELLOW
    obj.speed -= 1
    return inner

Evidently, this is regarded as "very JavaScript-y". I find it terribly simple though, and preferable to stringing along a bunch of objects that inherit from a long chain of ancestors.

My job isn't on the line or anything here, but in such a situation is it really that critical to split these up into separate classes? The first example, at the least, seems fine because it really is just replacing one method with another, but in the second example, I'm definitely redefining object attributes, and I go a bit further than depicted here (replacing the object's self.draw() methods and that if it's necessary).

It might be bad, but it's so stupidly easy.

Is this a good example of how not to implement a strategy pattern?

1

Does enemy change their behavior post-initialisation ? If not, then your objects are inheriting from a base class, and you shouldn't implement inheritance with a strategy pattern, for several reasons :

  • Code readability. When you move function pointers around, execution path made less clear. How to know which function will be indeed called, given an instance ?
  • Initialization logic re-use. If you intend to call overriding logic every time you call Enemy(), there is a problem
  • Performance, although this doesn't matter much

Also, I personally I hope I never have to maintain code that would contain similar patterns than alt_action. Calculating an attribute from a base value is pushing code obscurity and instability to a whole new level, because now, not only correct initialization isn't guaranteed, but it's not even idempotent (e.g. initializing twice doesn't make it initialized correctly...).

In my opinion, you think too much about coding to do the job, while your code is much more than that. Code describe a structure of how things are and interact with each other. Code is also meant to be read and changed more than once. It should make you inclined to choose simple solutions with well-established conventions, over what you find easy.

  • From what I understood, performance isn't a factor in this kind of metaprogramming since the wrapper is only called the one time; however, I think I see what you're saying. It does feel pretty dirty to mess with certain attributes in this way - that's what prompted my question – user112358 Apr 3 '14 at 20:17
  • Readability is the key point. "With great power comes great responsibility", and Python is a very powerful language :). Note that, in OO language, you go for the nice inheritance trees first. You fall back to monkey patching when everything else fail. – Arthur Havlicek Apr 3 '14 at 20:24
  • I thought monkey patching had more to do with third-party object/third-party software (which I would consider part of the the "don't change objects you don't own" mantra) – user112358 Apr 3 '14 at 20:41
  • something like "Oh this implementation of events sucks, let me just whip up a decorator for this thing and…" – user112358 Apr 3 '14 at 20:42
  • It's about changing objects methods at run-time. Third-party patching is one of the possibilities, probably the most common, because it's working around patching the sources. It can come in handy, especially as last resort, but other solutions are often preferable. The more you monkey patch, the less the code is readable and the more chances conflicting changes appear. – Arthur Havlicek Apr 3 '14 at 20:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy