Is 'Strategy Design Pattern' no more than the basic use of polymorphism?

Question

In Strategy Design Pattern, what we do is

• Create a common interface.
• Implement a set of classes using that interface with overridden method(s).
• Let the run time to choose the actual class for an object which has the same type with that common interface and call the overridden method(s) which will resolve correctly according to the class.

My question is, Isn't it the basic example of polymorphism and method overriding we learn?

other than the possibility of using an abstract class too, replacing the common interface.

Answer 1

What you describe is a way to implement the strategy pattern. You also describe how to implement a whole lot of different designs, since there are many, many reasons why we might want to create a common interface, make different implementations, and select one at runtime for different situations.

There are also other ways to implement the strategy pattern.

But, you know, a design is not code. A design is a mental model of how the software works -- a human thing, not bits. A design pattern is a common way of composing solutions to common sorts of problems. Again it happens in your head and not in bits.

The strategy pattern in particular is about making objects with interchangeable algorithms, any of which could be used for a particular purpose.

So, yes, you define an interface... but it's not the interface to a data object -- it doesn't have getters and setters and state mutators, etc. The interface defines how the object interacts with the algorithm that is used for a particular purpose. A chess game might use a "Player" strategy, for example, with a method called "SelectNextMove".

And, yes you make implementations of that interface, but the implementations aren't "things" that become "parts" of the containing object, they are different algorithms that could be used to perform whatever function the object requires. A chess game could support many different strategies that could be used to select the next move for the computer player.

So when you're thinking about the design of a chess game, for example, in your head, you will probably find it useful to think about strategy for choosing the next move separately from the objects that model the board and ensure that the selected move is recorded, communicated, and rendered properly. The strategy for choosing the next move is independent of these things.

If you're a good software designer, you will code it independently too, so that the separation of concerns in code will mirror the separation of concerns in your head, make it easy for people maintaining the code to think about it in the most useful way, and allow new strategies for choosing the next move to be swapped in and out whenever you want.