Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
"Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it." (Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995)
Many algorithms exist for breaking a stream of text into lines. Hard-wiring all such algorithms into the classes that require them isnt desirable for several reasons: (1) Clients that need linebreaking get more complex if they include the linebreaking code. This makes clients bigger and harder to maintain, especially if they support multiple linebreaking algorithms. (2) Different algorithms will be appropriate at different times. We dont want to support multiple linebreaking algorithms if we dont use them all. (3) Its difficult to add new algorithms and vary existing ones when linebreaking is an integral part of a client. These problems can be avoided by defining classes that encapsulate different linebreaking algorithms. An algorithm thats encapsulated in this way is called a strategy. Suppose a Composition class (Context in the thumbnail) is responsible for maintaining and updating the linebreaks of text displayed in a text viewer. Linebreaking strategies arent implemented by the class Composition. Instead, they are implemented separately by subclasses of the abstract Compositor class (Strategy in the thumbnail). Compositor subclasses implement different strategies: (1) SimpleCompositor (ConcreteStrategy in the thumbnail) implements a simple strategy that determines linebreaks one at a time. (2) TeXCompositor (ConcreteStrategy in the thumbnail) implements the TEX algorithm for finding linebreaks. This strategy tries to optimize linebreaks globally, that is, one paragraph at a time. (3) ArrayCompositor (ConcreteStrategy in the thumbnail) implements a strategy that selects breaks so that each row has a fixed number of items. Its useful for breaking a collection of icons into rows, for example. A Composition maintains a reference to a Compositor object. Whenever a Composition reformats its text, it forwards this responsibility to its Compositor object. The client of Composition specifies which Compositor should be used by installing the Compositor it desires into the Composition.
This pattern has been used on the following systems: Strategies define different register allocation schemes (RegisterAllocator) and instruction set scheduling policies (RISCscheduler, CISCscheduler) in the RTL System for compiler code optimization. This provides flexibility in targeting the optimizer for different machine architectures. (Johnson, R.E., C. McConnell, and J.M. Lake. The RTL system: A framework for code optimization. In Robert Giegerich and Susan L. Graham, editors, Code Generation--Concepts, Tools, Techniques. Proceedings of the International Workshop on Code Generation, pp. 255-274, Dagstuhl, Germany, 1992. Springer-Verlag.) The ET++Swaps Manager calculation engine framework computes prices for different financial instruments. Its key abstractions are Instrument (different instruments are implemented as subclasses of Instrument) and YieldCurve (calculates discount factors to present value of future cash flows). Both classes delegate some behavior to Strategy objects. (Eggenschwiler, T. and E. Gamma. The ET++SwapsManager: Using object technology in the financial engineering domain. In Object-Oriented Programming Systems, Languages, and Applications Conference Proceedings, pp. 166-178, Vancouver, British Columbia, Canada, October 1992. ACM Press.) The Booch components use strategies as template arguments. The Booch collection classes support three different kinds of memory allocation strategies: managed (allocation out of a pool), controlled (allocations/deallocations are protected by locks), and unmanaged (the normal memory allocator). These strategies are passed as template arguments to a collection class when its instantiated. (Booch, G. and M. Vilot. The design of the C++ Booch components. In Object-Oriented Programming Systems, Languages, and Applications Conference Proceedings, pp. 1-11, Ottawa, Canada, October 1990. ACM Press.) RApp, a system for integrated circuit layout, must lay out and route wires that connect subsystems on the citcuit. The routing algorithms are defined as subclasses of an abstract Router class. Router is a Strategy class. (Gossain, S., D.B. Anderson. Designing a class hierarchy for domain representation and reusability. In TOOLS 89 Conference Proceedings, pp. 201-210, CNIT Paris--La Defense, France, November 1989. Prentice Hall.) Borlands Object Windows uses strategies in dialog boxes to ensure that the user enters valid data (i.e. a numeric field should accept only digits). Validator objects are used to encapsulate validation strategies. These Validators are the Strategy objects. (Borland International, Inc., Scotts Valley, CA. A Technical Comparison of Borland Object Windows 2.0 and Microsoft MFC 2.5, 1994.)
Flyweight pattern
Flyweight pattern, Strategy pattern, behavioral patterns, Gamma patterns, Policy pattern, encapsulation (algorithm), family of algorithms, interchangeable algorithms
any system with high degree of behavioral variation
need many algorithms with variationneed to break up many behaviors with multiple conditionsthe data that is used by the algorithm should not be seen by the clientthere are many related classes that differ only in their behavior
allows you to vary the behavior of a class independent of its contextprovides a mechanism for decreasing the number of conditional statementsprovides hierarchies of behavioral reuse
a client of the strategy must understand the various strategies in order to select oneincreased number of objectspotential overhead on parameter passing - not all concrete strategies may use everything passed
Simple implementation of the pattern - Strategy class. Strategy.javaSimple implementation of the pattern - ConcreteStrategyC class. ConcreteStrategyC.javaSimple implementation of the pattern - ConcreteStrategyB class. ConcreteStrategyB.javaSimple implementation of the pattern - ConcreteStrategyA class. ConcreteStrategyA.javaTest driver teststrategy.cppTest driver testroute.cppSimple implementation of the pattern. strategy.hSimple implementation of the pattern. routetypes.hSimple implementation of the pattern. routestrategy.h