The context/strategy separation enables to overcome the limitations of inheritance, as far as protocol composition goes. One could for example optimize the reliable multicast algorithm and use it in some protocol classes, while leaving it unchanged in others. Protocol algorithms could even be dynamically edited and/or chosen, according to criteria computed at runtime; this feature is analogous to the dynamic interpositioning of objects. There is a minor compatibility constraint among different protocol algorithms in order to make them interchangeable: new algorithm class Algo can replace default Algo in protocol class Object if and only if Algo requires a subset of the services featured by Object.
This approach also helps protocol programmers to clearly specify, for each protocol , what are its dependencies with other protocols. One drawback of the Strategy pattern is the overhead due to local interactions between strategies and contexts. In distributed systems however, this overhead is small compared to communication delays, especially when failures and/or complex protocols are involved. More specifically, the time for a local Smalltalk invocation is normally under 100 , whereas a reliable multicast communication usually takes more than 100 ms when three or more protocol objects are involved (without even considering failures). The gain in flexibility clearly overtakes the local overhead caused by the use of the Strategy pattern.