Context Independence

[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

Solution

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

Resulting Context

Known Uses

Example

Related Patterns


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?


EditText of this page (last edited July 22, 2005)
FindPage by browsing or searching

This page mirrored in ComponentDesignPatterns as of April 29, 2006