The Strategy design pattern solves problems like:
How can a class be configured with an algorithm at run-time
instead of implementing an algorithm directly?
How can an algorithm be selected and exchanged at run-time?
See Applicability section for all problems Strategy can solve. See Solution section for how Strategy solves the problems.

• An inflexible way is to implement (hard-wire) an algorithm directly within the class (Context) that requires (uses) the algorithm. Conditional statements (switch(…)) are needed to switch between different algorithms.
• This commits (couples) the class to particular algorithms at compile-time and makes it impossible to change an algorithm later independently from (without having to change) the class. It makes the class more complex, especially if multiple algorithms are needed, and stops the class from being reusable if other algorithms are required.
  "Hard-wiring all such algorithms into the classes that require them isn't desirable for several reasons:" [GoF, p315]   "Algorithms are often extended, optimized, and replaced during development and reuse." [GoF, p24]
  
• That's the kind of approach to avoid if we want to configure a class with an algorithm at run–time.
• For example, reusable classes that support different algorithms.
  A reusable class should avoid implementing algorithms directly so that it can be configured with an algorithm at run-time.
• For example, calculating prices in an order processing system.
  To calculate prices in different ways (depending on run-time conditions), it should be possible to select the right pricing algorithm at run-time (see Sample Code / Example 2).
• For example, sorting objects.
  To sort objects in different ways, it should be possible to parameterize a sort operation with a compare algorithm (see Sample Code / Example 3).