Injectable ordering

The pattern occurs when module A needs to be mutated twice, with the first mutation occurring before some action which is coupled to module B’s concerns, and a final time as a required consequence of the initial mutation.

Here’s a simple example in Swift where a collection of objects need to write their positions into a render buffer:

Here’s the very simple code that uses the Render

For starters, BallThrower needs out of band knowledge to use the renderer which is not developer friendly. This could be better articulated. That RenderBegin() and RenderEnd() need called before/after RenderBall() is a concern of the Renderer, not the BallThrower, so this is a violation of concerns. Finally, the object is not in stable state until all three calls are complete, which violates the principle of Stable State.

Better is to use Injectable Ordering:

State isn’t floated between calls which is more functional, threadsafe, etc.
It’s in class BallThrower’s concern to return nil of values that are out of it’s bounds. This is simply articulated by using the option parameter.
The ordering of the rendering (which is the Renderer’s concern) is controlled by the Renderer (image a situation in which the renderer finds it faster to z-sort the balls instead of using a depth buffer, this implementation offers more flexibility for that refactoring).

Leave a Comment

Filed under Senior Engineering Patterns

Leave a Reply

Your email address will not be published. Required fields are marked *