Implementing Strategy Pattern Without Significant Branching

designdesign-patternsstrategyunit testing

The Strategy pattern works well to avoid huge if…else constructs and make it easier to add or replace functionality. However, it still leaves one flaw in my opinion. It seems like in every implementation there still needs to be a branching construct. It might be a factory or a data file. As an example take an ordering system.

Factory:

// All of these classes implement OrderStrategy
switch (orderType) {
case NEW_ORDER: return new NewOrder();
case CANCELLATION: return new Cancellation();
case RETURN: return new Return();
}

The code after this doesn't need to worry, and there is only one place to add a new order type now, but this section of code still isn't extensible. Pulling it out into a data file helps readability somewhat (debatable, I know):

<strategies>
   <order type="NEW_ORDER">com.company.NewOrder</order>
   <order type="CANCELLATION">com.company.Cancellation</order>
   <order type="RETURN">com.company.Return</order>
</strategies>

But this still adds boilerplate code to process the data file – granted, more easily unit testable and relatively stable code, but additional complexity nontheless.

Also, this sort of construct doesn't integration test well. Each individual strategy may be easier to test now, but every new strategy you add is addition complexity to test. It's less than you would have if you hadn't used the pattern, but it's still there.

Is there a way to implement the strategy pattern that mitigates this complexity? Or is this just as simple as it gets, and trying to go further would only add another layer of abstraction for little to no benefit?

Best Answer

Of course not. Even if you use an IoC container, you will have to have conditions somewhere, deciding which concrete implementation to inject. This is the nature of the Strategy pattern.

I don't really see why people think this is a problem. There are statements in some books, like Fowler's Refactoring, that if you see a switch/case or a chain of if/elses in the middle of other code, you should consider that a smell and look to move it to its own method. If the code within each case is more than a line, maybe two, then you should consider making that method a Factory Method, returning Strategies.

Some people have taken this to mean that a switch/case is bad. This is not the case. But it should reside on its own, if possible.

Related Solutions

Design Patterns – Can the Strategy Pattern Be Overused?

What you're talking about is programming to abstractions, which does not imply the Strategy pattern.

Programming to abstractions is always a good practice. There's virtually no additional effort involved in providing an interface or abstract base class for a concrete implementation, and many refactoring tools can now do this automatically for you.

How abstract to make it is a different question.

In your first example, you simply have an abstract type. You could program everything to use a generic Serializer or ISerializer type and then wire up a single default implementation in an IoC container like Castle or Spring. Simple. Done.

In the second instance, though, you're designing abstract functionality. You're trying to predict how this abstract type might be used in the future, and you are probably going to be wrong. The YAGNI principle applies here; unless you have some reason to believe that your application actually needs a fully-generic "transform" interface which can turn anything into anything else, and unless you've actually scoped out the requirements for it, then you're wasting your time planning for it. Maybe you should just use one of the many existing XML transformation languages if you need that kind of flexibility.

None of this really has anything to do with the strategy pattern. The strategy pattern means that not only are you coding against an abstract type, but that you are choosing which concrete type to use based on information only known at runtime. This is neither explicit nor implicit in your question.

If you only have one implementation, then implementing a strategy pattern is absolutely overkill, unless you know for sure that you will need to support additional strategies almost immediately afterward.

But that does not preclude you from using abstract types. This is generally how most OO applications are designed now, using dependency injection for code and an IoC container for configuration. I'd go so far as to say this is more productive than coding to concrete types, because (a) it's much easier to test and mock, and (b) quickly coding an interface allows you to continue your current task without much distraction, as opposed to going off and writing a whole new class because you can't continue without it.

So definitely make use of abstract types, but don't overthink things and spend a lot of time fussing about how to generalize them. It's easier to refactor later than it is to work with a bloated interface.

Java – Implementing strategy pattern multiple variables

The intent of the strategy pattern according to the GoF is to "define a family of algorithms, encapsulate them and make them interchangeable. The strategy lets algorithms vay independently from client that use it"

In your code you apply this pattern, making a strategy of ContentHandler that can be declined in different concrete content handling, depending on the requests to pursue.

Problem with the switch approach:

However, in your implementation the serialization depends on the format you want to use. The way you pass a content type, using lots of switch blocks to produce the appropriate format, will make the code very difficult to maintain: each content handler implementation will have to provide for all kind of formats. Imagine that one day you'd like to add a new format (for example bson) : you'd need to review all the switch blocks of all your concrete implementation of ContentHandler. That's a huge work, and clearly does not very well enforce separation of concerns.

Alternative:

But looking at it more closely, you have here an opportunity to add a second level of strategies. Each of your switch block would correspond to a kind of primitive operation on the content to produce the format. It's another family of algorithms. You should hence make the format a strategy as well:

public interface SerialFormatter {
    String createStringNode(...);  
    String openSubbloc(...);  
    ... // you have to analyze your switch blocks to determine the primitives
};

And then regroup all format specific primitives according to this logic:

class JSONFormatter implements SerialFormatter { ... }; 
class XMLFormatter implements SerialFormatter { ... };

If one day you want to support a new format, just add a new class of this kind.

You then can simplify your serializer logic:

String serializeRequest(Content con, SerialFormatter fmt){
   // ....
   String s = fmt.openSubbloc ("ID") + 
       fmt.createStringNode ("Name", con.name() ) +
       ...
       fmt.closeSubbloc("ID"); 
   return s;  
 }

Conclusion

Design using combination of multiple strategies is sometimes called "policy based design" It is a very powerful approach: with n kind of requests and m format, you'd write m+n classes with single responsibility, instead of writing nm classes (see other answer to your question) or writing n classes and at least nm rather redundant cases.

Best Answer

Related Solutions

Design Patterns – Can the Strategy Pattern Be Overused?

Java – Implementing strategy pattern multiple variables

Related Topic