What do I gain by using the Strategy pattern in this case?

Question

I wrote a program with Java that plays simple music. Currently chords have only one way ('strumming pattern') to be played. I want to expand this and create different 'strumming patterns' that chords can use to play their notes.

The Chord class has a play() method that is responsible for playing the chord. Currently it contains the logic for the only 'strumming pattern' of how the notes are played.

To add new strumming patterns, the simplest approach is to change play() to something like this:

void play(int strummingStyle){
    if(strummingStyle == REGULAR_STYLE) playRegular();
    if(strummingStyle == SOMETHING_ELSE_STYLE) playSomethingElse();
    // .. etc
}

Have a method for each strumming style, and parameterize the method to play a specific style.

However using the Strategy pattern feels like a better approach. What I mean is to encapsulate each strumming pattern in a subclass of StrummingPattern and set the Chord to a specific strumming pattern: chord.setStrummingPattern(StrummingPattern pattern);.

play() would then simply delegate to the strumming pattern like so:

void play(){
    pattern.play();
}

While this clearly feels like the better, more OO approach - I find that I can't explain myself what the actual benefits are. And it's important for me to actually understand why I'm doing something.

Please explain why using the Strategy pattern in a case like this is a better approach than the more naive 'a method represents a behavior' approach. What exactly are the Strategy pattern's benefits in this kind of situation? Why should I use it?

Answer 1

In the first example you need to modify an existing class to add new behaviour, in the second with the strategy pattern you can add new funcionality to your system adding new classes and without modify the current code (or with minimal modifications).

This has a lot of advantages:

• Less risk of breaking existing functionality
• Smaller classes vs classes that grow and grow
• Better for teamwork, think in N programmers each one adding new "strumms" at the same time with the two approaches
• Your systems its more extensible, in the future you can make this api public and other people can add new elements (chords, strumms) to your system

In terms of SOLID, the second solution its more Open-Close and as a consequence the resultant classes are more Single responsability.

Use SOLID, GRASP, or other OO principles like cohesion and coupling,think in the cost of adding new functionally, think in the cost of understanding the system for a new programmer as tools to evaluate your designs and learn to decide WHY a design its better or not than other. The patterns often offers good solutions or pointers (often not) you need to rely on more fundamental principles of OO to evaluate and know WHY, you are in the good direction if you "feel" that needs this Why's, its better to not use patterns than to use then blindly.

Answer 2

"However using the Strategy pattern feels like a better approach"

Yes. :)

Your instincts are right on this one.

In OO, you want to avoid that kind of "if this, do this; if that do that" logic, because the type system handles that for you very elegantly. (I actually have an aversion to if...then logic in general, because as the logic branches it makes my brain hurt more and more).

(A corollary, if you're checking types with if blah instanceof Blah, then you probably need to think harder about your OO design, because you're cheating on polymorphism and peeking at the underlying type. The class should just know what it needs to do, and the caller should just know how to call it.)

The main advantage of the Strategy pattern is leveraging the dynamic dispatch aspect of the language to do the "if...then" block for you. So you only have to make sure your Strategy classes are correct and that the consumer of them calls the play() method correctly. It scales in complexity better, because you can just drop in new strategy classes over time. Testing is tons and tons easier, because it's all nicely decoupled.

...

If you want to convince yourself, do it both ways. Write an example with 5 alternatives as the block of "if...thens", and another example with 5 alternatives in the strategy pattern.

Then write unit tests to 100% coverage for both cases.

;)