Strategy
If you are developing a body of work where the implementations available for a particular operation can be changed then there are a number of options regarding how you might implement this. It could be that you might implement a type hierarchy with a gene
- PDF / 188,450 Bytes
- 5 Pages / 439.37 x 666.14 pts Page_size
- 106 Downloads / 193 Views
Strategy
30.1
Introduction
If you are developing a body of work where the implementations available for a particular operation can be changed then there are a number of options regarding how you might implement this. It could be that you might implement a type hierarchy with a generic or abstract method at the root of the hierarchy and sub types providing alternative implementations of that method as required. It would then be possible to select between completing implementations based on the type that is instantiated. However, in some cases it may be necessary to alter the implementation of an operation without changing the type (or the identity) of the encompassing object. In this situation instantiating a whole new object would lose the identity and may result in additional, unnecessary objects being created. The Strategy pattern provides an approach to this problem that allows the implementation of an operation can be changed dynamically at runtime.
30.2
Pattern Classification
Gang of Four Behavioural Pattern
30.3
Intent
To allow the algorithmic implementation of some behaviour to be selected as required (and to be changeable over time).
J. Hunt, Scala Design Patterns: Patterns for Practical Reuse and Design, DOI 10.1007/978-3-319-02192-8_30, © Springer International Publishing Switzerland 2013
239
240
30.4
30
Strategy
Context
Being able to plug in different implementations for an operation is a common requirement in a number of different situations. For example, being able to use different encryption and decryption algorithms, or different algorithms for breaking a stream of text into lines, or different algorithms for calculating tax payments or pension rights etc.
30.5
Forces/Motivation
The Strategy Pattern can be used when • An application must be able to change the implementation of an operation at runtime or must be able to change it based on some selection criteria. • The differences in implementation (algorithm) can be encapsulated into the strategy and there is a consistent approach to accessing these different implementations. • Clients do not need to know anything about how the operations are implemented. • Switching between different instances of different classes would lose identity integrity.
30.6
Constituent Parts
There are a number of roles in the Strategy Pattern. These are: Client The invoker of the behaviour implemented by the strategy. Strategy The abstract concept represented by the implementations of this strategy; may be given a name to provide semantic meaning to the strategy (such as a name indicating the purpose of the strategy). In Scala may be defined as a function indicating the number and type of parameters expected and the return type generated. Concrete Strategy One or more implementations of the operation(s) indicated by the Strategy abstraction (in Scala this may be one or more functions that implement the function specification provided by the Strategy). The Context A container for the concrete strategy. This may be an encapsulating Object, Class or Tra
Data Loading...
