Automated Assembly

Context

You are building a component-based framework based on AbstractInteractions and ThirdPartyBinding.

Problem

How do you ensure that users of the framework compose components correctly.

Forces

• Components can be composed in many ways but not all possible compositions are valid.
• No customization, modification, or extension of components or the component framework can make it difficult for the application to be flexible to changing requirements.
• Instantiating and binding components is a complex and/or boring task. For example, it might involve a lot of boiler-plate code, which is a potential source of errors, or involve tricky concurrency issues such as race conditions which must be guarded against when composing components.
• Too much flexibility can place an unneeded burden upon the user who essentially needs to manually assemble the application before using it. It would be like buying a car and getting it shipped to you in a box full of pieces.

As part of your framework, provide PrebuiltFunctionality that can automatically instantiate and connect the correct components to perform common tasks.

Resulting Context

It is easier for framework users to make use of the framework for common tasks.

It is no harder to use the framework for tasks that are not supported by AutomatedAssembly.

Components need to support InterfaceDiscovery so that AutomatedAssembly functions can interrogate and connect their interfaces.

Components that SplitDesignTimeAndRunTime representations can only be assembled at design/build time, which makes it harder to adapt the system at run-time or without rebuilding the system.

Known Uses

The DirectShow framework provides a graph builder object that can automatically instantiate and connect the correct filters to render a media file. It can also connect an output pin of a filter to an input pin of another and instantiate the correct filters to convert between the formats of two pins.

The Regent distributed programming environment includes a "Stacker" class that that, given the name of a protocol, automatically instantiates protocol components and composes them into a compatible stack.

Microsoft's ActiveX development tools include "wizards" that generate huge amounts of boilerplate code. Personally, I distrust wizards because they allow lazy programmers to generate large amounts of code without actually understanding what they are doing, which causes problems as soon as they hit a bug.

This is quite similar to the approach David Canfield Smith and I took when we were building a component system with automatic assembly, back in 1991-92. We chose a system where components were connected in a dataflow style and were annotated with metadata describing their connectors. I think I like a more OO approach to the component interface descriptions. The results of our work are documented in:

Smith, David C. and Joshua Susser. "A Component Architecture for Personal Computer Software," Languages for Developing User Interfaces, pp31-56, Brad Myers ed. Boston: Jones & Bartlett, 1992.

This page mirrored in ComponentDesignPatterns as of April 29, 2006