When to choose Strategy over polymorphism when refactoring switch statement

Question

Can you give me specific reason when to choose stratergy over polymorphsim and vice versa.

Thanks a lot!

Answer 1

One criterion that's important is whether polymorphism would create coupling that strategy would avoid. For example, if implementing a "save()" method for a tree of classes meant using low-level I/O functions, then if you use polymorphism, the tree of classes would become coupled to the I/O system whereas it wasn't before. If you use the strategy pattern, however, then the strategy objects will serve as a "buffer" and keep the tree of classes from depending on I/O.

Answer 2

You start your application with null.

Next step is raw code with polymorphism.

With basic cases it can stay in that way - that's not a problem.

If you want your application to be more flexible, prepared for changes and you plan to continue developing it - it's time to look for some design-patterns, Strategy is one of those about witch you should think, when polymorphism is giving some troubles.

---

Intent of Strategy:

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

---

Motivation to use Strategy:

Many algorithms exist for breaking a stream of text into lines.Hard-wiring all such algorithms into the classes that require them isn't desirable for several reasons:

· Clients that need line breaking get more complex if they include the line breaking code. That makes clients bigger and harder to maintain, especially if they support multiple line breaking algorithms.

· Different algorithms will be appropriate at different times. We don't want to support multiple line breaking algorithms if we don't use them all.

· It's difficult to add new algorithms and vary existing ones when line breaking is an integral part of a client. We can avoid these problems by defining classes that encapsulate different line breaking algorithms. An algorithm that's encapsulated in this way is called a strategy.

---

Consequences:

1. Families of related algorithms.Hierarchies of Strategy classes define a family of algorithms or behaviors for contexts to reuse. Inheritance can help factor out common functionality of the algorithms.

2. An alternative to subclassing.Inheritance offers another way to support a variety of algorithms or behaviors. You can subclass a Context class directly to give it different behaviors. But this hard-wires the behavior into Context.It mixes the algorithm implementation with Context's, making Context harder to understand, maintain, and extend. And you can't vary the algorithm dynamically. You wind up with many related classes whose only difference is the algorithm or behavior they employ. Encapsulating the algorithm in separate Strategy classes lets you vary the algorithm independently of its context, making it easier to switch, understand, and extend.

3. Strategies eliminate conditional statements.The Strategy pattern offers an alternative to conditional statements for selecting desired behavior. When different behaviors are lumped into one class, it's hard to avoid using conditional statements to select the right behavior. Encapsulating the behavior in separate Strategy classes eliminates these conditional statements.