Project Developed Reuse

Context

The project team is working in an organization that has development teams developing applications and a centralized reuse team that is responsible for managing reusable components.

Project architects and designers utilized CautiousBuyOverBuild or StealOverBuy, and determined one or more components are candidates for reuse.

Problem

Which team builds the reusable components?

Forces

• Component developers outside the project team that wishes to build these reusable components can become isolated, developing in an ivory tower that yields fancy but useless features.
• Developers on project teams often lack the necessary skills to develop truly reusable and adequately documented components.
• Isolated component developers are often not in the position to adequately communicate with architects, designers, assemblers, or business users of reusable components, resulting in components that don’t fully meet requirements.
• Time to market pressures can make it virtually impossible for even capable reusable component developers on project teams to develop quality, adequately documented reusable components.
• Often a specific implementation is needed before components can be genericized into reusable ones.
• Isolated component developer may not understand the business domain.

Implement the early versions of a project’s candidate reusable components within project teams developing applications.

Save the task of genericizing and polishing candidate reusable components for the reuse team, which can perfect and maintain, educate, and deploy subsequent versions.

Involve the reuse team in establishing standards and guidelines to component-based and object-oriented design principles geared toward assisting project developers in building higher quality components that can be reused and maintained more effectively.

A variation of this pattern is to allow a member of the reuse team to join the initial versions of a project containing candidate reusable components.

Resulting Context

If you’re developing a generic framework consisting of components that interact and can be extended by others to solve a concrete business problem, LayeredFrameworks can reduce complexity and increase reusability.

Developers can document UsagePreconditions for each candidate reusable component resulting in increased reusability. Documented preconditions can reveal otherwise hidden dependencies, allowing component assemblers and developers to better understand its underlying implementation dependencies and potentially BypassAbstractions? if required.

ContainerIndependence can increase reuse and allow component developers to use lightweight test containers for unit testing purposes.

Known Uses

Example

Related Patterns

This page mirrored in ComponentDesignPatterns as of April 29, 2006