Strategy decorator

Other usages

The strategy decorators may or may not have a state. In most cases strategy decorators will be stateless, since the main purpose of this pattern is to add or alter behavior. Stateless strategy decorators can be injected into a context using the Dependency Injection
design pattern, instead of passing the strategy to the context as an argument.
Stateful strategy decorators can be used for local calculations based on their state, and they can mutate their state during a business process, to create a chain of calculations e.g. Stateful strategy decorators can be used as well in a command pattern style holding the state that is needed to perform a certain action, to create a chain of commands e.g.

Interface evolution

Given, a team works on a context using a new strategy interface, but another team working in parallel is responsible for the implementation of that strategy interface. And the operations needed for that strategy interface are not yet fully specified and predictable, but both teams cannot wait for the specification due to their deadlines.
Then, in order to parallelize work and to avoid issues with the collaboration of both teams, we could decouple the work packages of both teams using the Strategy Decorator pattern. With the Strategy Decorator pattern it is not required to specify the interface upfront. Instead we can develop the interface gradually, driven by the context that uses the interface, without any interference between the teams.
Team one, working on the context, can add operations to the strategy interface as needed for the context, along with the forwarding to the decorated strategy. Team two, responsible for the strategy implementation, can implement and add decorators for the operations added by team one anytime later.
If an operation becomes obsolete for the context, team one marks the operation as deprecated. Team two can remove implementations anytime later.
If the signature of an operation has to be changed for the context, team one marks the operation as deprecated and creates a new operation with the required signature. Team two can adapt the implementations anytime later.

Nesting

The creation of a decorator can be nested within another decorator and hence the creation of a strategy can be nested within another strategy . The nesting decorator / strategy is also called the outer decorator / strategy and the nested decorators / strategies are also called the inner decorators / strategies. This should not be confused with the parent-child relationship of chained decorators where the child-decorator is passed to the parent-decorator as an argument.
A context can get an inner strategy from an outer strategy and may pass it to subordinated contexts. To realize main-sub process relationships with strategies dedicated strategies can be created for and passed to each main- or subprocess.
Inner strategies can be decorated within the outer strategy before returning them to a context. Thus, we can create a dedicated strategy in one place and over decorate that strategy in another place. A team may work on a subprocess and create provisional decorator dummies for their inner strategy while another team working in parallel over decorates them with the real decorators.
Given, a team one works on a subprocess using an inner strategy passed to that subprocess. And a team two is responsible for the main process and the outer strategy. The main process gets the inner strategy from the outer strategy and passes it to the subprocess.
Then, team one creates the inner strategy in a decorator of the outer strategy and may or may not add provisional decorator dummies to their inner strategy as needed for the time being. Team two can independently from team one over decorate the inner strategy with the real decorators they implement. Hence, team two can replace provisional behavior from team one with the real behavior little by little, without any interference between the teams.