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

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.

Strategy implementation can be even simpler in dynamic languages such Javascript. Whenever you pass a callback arround, your are probably extending a Strategy implementation.

Example: sorting arrays

Javascript's native arrays have a method called sort that will return a brand new sorted array. It can have one parameter, the comparisonFunction, a callback that will compare 2 items in the array and return:

• 1 if the first element is to be considered higher than the second.
• 0 if it is to be considered equal
• -1 if it is to be considered lower then

So, you can use whatever strategy you want to sort the array:

[5, 2, 4, 1, 3].sort(); // default: sort in the natural order

[5, 2, 4, 1, 3].sort(function reverse(first, second){
    if (first > second) return -1;
    if (first == second) return 0;
    if (first < second) return 1;
});

[5, 2, 4, 1, 3].sort(function random(first, second){
    return Math.floor(Math.random() * 3) - 1;
});

When you are creating your on libraries and expect a callback that will do some work on your data, you are probably implementing the Strategy pattern.