ContextIndependence

Last edit February 11, 2008
[ComponentDesignPatterns | CategoryPattern]

Context

You are designing a system to be constructed from a mixture of third-party and home-grown components.

Problem

How do you make it easy (easier) to reuse components and maintain a system built from components?

Forces

  • A component that has implicit dependencies on the context in which it is used is harder to reuse in other contexts.
  • A system in which implicit dependencies exist between components is brittle - making a change to one component can break others which have an implicit dependency on it, but the cause of the failure will not be immediately obvious.

Solution

Replace implicit dependencies with explicit dependencies. One or more of these strategies might help:

Resulting Context

Known Uses

Example

Related Patterns

  • MartinFowler's "Dependency Injection" pattern is about making objects context independent.

See also

NatPryce: Feel free to add to, modify or clarify this pattern, especially the forces.

PhilipEskelin: Based on some of the discussion that occurred in AbstractInteractions, I've done more thinking about what we're talking about here. We're talking about the structure and behavior of interacting components and frameworks. But what about expected and unexpected life and death? I am, therefore I exist . . . but how did I come and how will I go? Perhaps another mini-pattern language called LifecycleMethods or the GameOfLife is in order?

I don't know if it's a part of ContextIndependence, or if we should have the GameOfLife contain LifePatterns, AbstractInteractions, and DeathPatterns -- all taking both foreign and domestic structural and behavioral forces into consideration. Thoughts?