This is an old revision of the document!
It is really a design decision. It is always possible to centralize the interaction code by rewriting the RoleMethods to become instance methods in the Context. The Roles are instance variables in the Context. The method names may have to be changed to avoid name clashes, and any occurrence of 'self' in the code must be replaced by the corresponding role name.
However, a difference between that kind of procedure orientation and object orientation is that in the former, we ask: “What happens?” In the latter, we ask: “Who does what?” Even in a simple example, a reader looses the “who” and thereby important locality context that is essential for building a mental model of the algorithm.
I guess a centralized architecture may be OK in simple cases, but the decentralized (DCI) architecture leads to more sophisticated mental model and code.
I think that the natural model is for roles to act like actors in a play, interacting with each other to carry out the work of the system.
Most of the time, putting the algorithm in the context is global procedural thinking: an all-knowing algorithm orchestrating conscribed objects to perform low-level operations on the behalf of the procedure. You can of course do that in DCI and of course can do it through generic interfaces, but it's not DCI.
Once in a while, though, I have a hunch that this context-centric algorithm has a place as one of the attendees pointed out last week. The example that gives me pause is the age-old example of drawing a shape on a window, where each object comes from its corresponding class hierarchy. I conjecture that the draw algorithm doesn't easily decompose in a way that fits naturally in either class or in any corresponding roles, and as such it belongs in the Context. I feel strongly that this is the exceptional case, but I want to make room for it if it's there.