Prebuilt Functionality

Context

You are defining a ComponentFramework in terms of AbstractInteractions.

Problem

Why would anyone want to learn the AbstractInteractions you have defined when they could build their application without the learning curve?

Forces

• It is a lot of work to learn a set of AbstractInteractions and built components that conform to those protocols.
• If you have a fixed set of requirements and there is no code that can be used to help you meet those requirements, it might be easier to develop a custom solution rather than develop components that conform to someone else's AbstractInteractions.
• If most of your system can be built out of preexisting components that can easily be integrated into a working shell, it is easier to write the missing functionality in terms of that framework than it is to develop a system from scratch.
• If a framework includes many components it can take time to evaluate which components are suitable for use in a project and how they can be parameterized and modified, and which components need to be developed from scratch.

Provide prebuilt components and/or framework code that implement various roles of the AbstractInteractions and provide the basic functionality required to get an application up and running.

Resulting Context

Users of your framework can quickly integrate your components into a working system and need only write a few custom components for their particular needs.

Users of your framework might find it hard to select appropriate components. Good documentation and/or a CookbookApproach can help here.

Related to the point above, providing functions that perform AutomatedAssembly of components to achieve common tasks can help users climb the learning curve.

Known Uses

As well as DirectShow, which is described in detail in the Example section...

The Regent transport protocol includes prebuilt protocol components that encapsulate the operating system's networking API and enhance existing protocols with security, logging, lightweight connections, etc. Further PrebuiltFunctionality supports the naming of composite protocol stacks and the AutomatedAssembly of named stacks.

The widgets in the Abstract Windowing Toolkit of Java 1.1 are JavaBeans meaning that there were already a number of useful components available that could be manipulated by graphical development tools before those tools were released.

Example

Microsoft's DirectShow is a framework for processing and presentation of continuous media. Media streams flow through filters, each of which performs some processing: "source" filters read media from a disk or file, "parser" filters split raw data into typed frames according to some encoding format, "transform" filters modify frames that flow through them and "sink" filters render frames on some presentation device such as a video window or audio card.

Filters pass frames and control information to each other through COM interfaces. Sets of interfaces define AbstractInteractions that encapsulate how filters work together to complete certain tasks, such as negotiation of media types or flow control. DirectShow defines many COM interfaces.

Windows already includes far simpler APIs to play media files. Why would anyone bother learning all those interfaces and how they fit together in order to play media files? Because The DirectShow runtime includes many prebuilt components that provide useful functionality:

• A graph builder component performs AutomatedAssembly of a filter graph to render a source of media, selecting the appropriate filters to parse the format of the media and render it once parsed.
• There are at least two standard source filter types: one reads data from a disk file the other from a URL. These are independent of the format of the media being read.
• There are many prebuilt parsing filters that can parse widely used media types. These filters are independent of where the media actually comes from.

If an application needs to render a custom media format the programmer can write a parser filter for that format. They will then be able to play their custom files from disk and, with no further work, be able to stream their custom files from a web server. Moreover, they can ship their component to other users and they will also be able to play their custom files, both from the disk and from the web.

If they need to transmit media over their own network protocol, they can write a sink filter to transmit that data and a source filter to receive that data. They will then be able to use their network protocol to deliver any media type understood by DirectShow.

Related Patterns

The amount of PrebuiltFunctionality available for a framework is a guiding factor when considering CautiousBuyOverBuild.

This page mirrored in ComponentDesignPatterns as of April 29, 2006