[
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?