Explicit Context Dependencies

As a follow up from my last post about Global Container vs. Injected Context, I would like to share this snippet from Component Software, which casts the difference between the two approaches in another light:

"A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. ..."

Under this definition, the ControllerProvider based upon an Injected Context is a component, because it publishes its (admittedly broad) context dependency explicitly, via its constructor parameter.

BadControllerProvider, based upon a Global Container, is not a component under this definition because its dependency on the global container is not explicit (you need to have source code in order to find it.)

In my opinion, the distinction is significant because "components" and "wiring" are a higher-level abstraction than "classes" and "references".

In composite applications, an architecture will be more robust and easier to understand if these layers of abstraction are respected, and not tangled up in classes like BadControllerProvider.

(Component Software is a very worthwhile read and contains a lot of relevant material for those interested in IoC containers and other composition technologies. Clemens Szyperski is a mentor and highly influential voice for the MEF team.)

Comments (1)
  1. Bryan Watts says:

    Calling upon a static implementation, such as a Global Container, is the highest form of coupling – there is no room for abstraction. The context of an entire app domain is assumed, which precludes more-specific contexts.

    Components, by definition, cannot assume any context, so they cannot rely upon static implementations.

    This principle can help ensure functionality is properly bounded. Thanks for the tip on the book!

Comments are closed.

Skip to main content