Strategy decorator

This article publishes a draft of a previously unreleased object-oriented design pattern

See also UML diagrams of the Strategy Decorator pattern on the next pages

Introduction

The Strategy Decorator design pattern is a behavioral software design pattern that enables selecting an algorithm at runtime. It lets the algorithm vary independently from the clients using it. The Strategy Decorator pattern makes it possible to add or alter behavior without changing existing implementations and it makes it possible to add or alter behavior of an individual interface operation dynamically at runtime in a multilayered and arbitrary combination.

Context

We have to implement a complex business process or we have to heavily change the implementation of a complex business process. During that process we have to choose between alternative behaviors. Typically, we have to determine by parameters which behavior shall be choosen to dispatch the process accordingly. The way we implement the dispatch shall not restrict the types or the number of the parameters we could use to determine a behavior.
The parameters may or may not relate to each other hierarchically. The behaviors which could possibly be choosen may or may not relate to each other hierarchically, no matter if the parameters relate to each other hierarchically. For instance the same behavior might be choosen by different sets of parameter values and even by sets of parameters with different parameter types. The way we implement the dispatch shall facilitate to implement new behaviors, to add implemented behaviors to the process and to remove them from the process.
We shall split the implementation of the behaviors into small work packages in order to facilitate a parallelization of the work.

Problem

With traditional code using conditional statements like if-then-else, the code will become hard to understand as well as hard to change.
Conditions might be too complex and inconsistent. Some implementations of behavior might be duplicated.
We could use the Strategy Design Pattern, but for each change of the strategy interface, for instance when adding an operation, we would have to adapt all strategies and the single dispatch nature of the Strategy Design Pattern somewhat restricts the number of parameters we can use for the dispatch. When we dispatch by more than one parameter the strategies often become cluttered and hard to understand.
To support several parameters which relate to each other hierarchically, we could build a hierarchy of inherited behavior, but we would have to adapt the hierarchy on each change of the strategy interface and to choose the same behavior for different sets of parameter values or for different parameter types, we might have to duplicate some implementations.
A strategy implements all operations of the strategy interface and can become a quite huge piece of code. Implementations of operations are not decoupled and hence it is possibly not easy to parallelize the work.