CSC/ECE 517 Fall 2007/wiki1b 8 sa: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 37: Line 37:


Normally there are 3 types of classes and or objects that participate in a strategy pattern
Normally there are 3 types of classes and or objects that participate in a strategy pattern
    * Strategy   
* Strategy   
          o declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy
** declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy
    * ConcreteStrategy   
* ConcreteStrategy   
          o implements the algorithm using the Strategy interface
** implements the algorithm using the Strategy interface
    * Context   
* Context   
          o is configured with a ConcreteStrategy object
** is configured with a ConcreteStrategy object
          o maintains a reference to a Strategy object
** maintains a reference to a Strategy object
          o may define an interface that lets Strategy access its data.
** may define an interface that lets Strategy access its data.


                          [[Image:Strategy-Example.jpg]]
[[Image:Strategy-Example.jpg]]


For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.
For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

Revision as of 23:36, 28 September 2007

Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) are editing this page.

Strategy Pattern

Strategy pattern is one of the several software design patterns, where in algorithms can be selected on-the-fly at runtime execution of the program. The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

Concept to explore

Take a case of the Strategy pattern and implement it as succinctly as possible in Ruby and Java. Compare the two implementations in terms of clarity and succinctness. The example should be a "real-world" example. While it may be grossly oversimplified for the purpose of illustration, it should not be totally contrived (i.e., should not raise the question, Why would anyone ever want to do that?).

Definitions

Design Patterns

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

Strategy Pattern

The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeagle. Stratergy lets the algorithm vary independently from clients that use it.

Polymorphism

Encapsulation

Composition

Inheritance

Related Patterns

Alternatives

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

Example & Illustration

Normally there are 3 types of classes and or objects that participate in a strategy pattern

  • Strategy
    • declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy
  • ConcreteStrategy
    • implements the algorithm using the Strategy interface
  • Context
    • is configured with a ConcreteStrategy object
    • maintains a reference to a Strategy object
    • may define an interface that lets Strategy access its data.

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

Real World Problem

Java's Solution

Ruby's Solution

Java versus Ruby

Comparision

Where Ruby wins?

References

See Also