Container Independence

[ComponentDesignPatterns | CategoryPattern]

[Below is the leftover old format; this pattern is undergoing a metamorphosis to Alexanderian form.]

Intent

Decouple one or more components from their container to the extent that other containers can be used in its place.

Motivation

Components with finer granularity (e.g. text boxes, buttons and other widgets) typically used to compose user interfaces are inherently container-independent. Many development environments and tools provide these widgets for rapid application development.

But sometimes large-grained components get coupled to the application that contains them operate independently of the application that contains them.

Known Uses

The first implementation of ContainerIndependence that saw wide-scale use was in the Collection classes for Smalltalk-80. Since then the practice has become widely accepted, influencing the design of the Java Collection classes and the C++ Standard Template Library. The package approach to CBD is now becoming an emerging standard. Today, companies like PeopleSoft and BaanCompany? are taking a component-based approach. When the container is a package, motivation becomes a "cautious integration" for components.

For example, In a previous project one of us participated in, we took Janna Contact from Janna Systems [2], a package for enterprise contact management, and extended it with a few dozen ActiveX controls (the components) that represented different kinds of financial data.

When our components were plugged into Janna, they used Janna as the means to base their information on contact info. ContainerIndependence gave us the ability to manually test-drive our controls in the Visual C++ test container. We demonstrated reusability to stakeholders by popping them into a web page on Internet Explorer. Showstoppers in Janna (e.g., database problems) didn't stop us because we just continued development, testing, and debugging with the test container.

Finally, ContainerIndependence is one of the main selling points (and design strategies) of EnterpriseJavaBeans.

Yes, I too have found this a key area for making contained objects reusable. It's often convenient for the object to have a back-pointer to its container, and this leads to a coupling which causes problems later.

If a component needs to communicate with its container, you can reduce coupling by defining AbstractInteractions between container and containee. --NatPryce

It also means the object cannot be in two containers at once. This may not matter much for GUI things but can be a problem generally. This is one of the reasons I was stunned by Smalltalk-like collection classes the first time I saw them. Previously (in C) I'd used IntrusiveLinkedLists?, which lack ContainerIndependence and don't lead to such reusable list code. -- DaveHarris

Use of the AbstractSessionPattern can help support ContainerIndependence. OLE calls these sites. Each embedded object holds a reference to a "site" object that represents its place in its container. It requests changes to it's location by calling methods of it's site. Containers instantiate a site object for each contained object and mediate between the sites to share screen real-estate between the contained objects. A really simple container, that only holds one contained object, can implement the site interface itself. -- NatPryce

A hypothesis:

The VisualBasic concept of an event which is raised by a control and caught by a container provides a simple language concept that ensures the control being contained needs no knowledge of the container. (Specifically, the control doesn't need an object reference or knowledge of some special interface implemented by its container.)
The containee->container relationships are defined by event propagation only.

Thus the event concept in VB exists to achieve ContainerIndependence.

This is pretty tentative. Feel free to confirm or deny this.