Prebuilt Functionality

[ComponentDesignPatterns | CategoryPattern]

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

Solution

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:

If an application needs to play standard media files a programmer can, in a few lines of code, instantiate a graph builder and tell it to render a file. The graph builder will select which existing filters to use.

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.


EditText of this page (last edited March 29, 2006)
FindPage by browsing or searching

This page mirrored in ComponentDesignPatterns as of April 29, 2006