The Reusability Principle

The Reusability Principle states:

Ideally, components should be easy to reuse.

In other words, we should be able to use instances of the same component in different systems.

This isn't always possible. Sometimes a component needs to provide additional services or the implementation of a provided service needs to be altered slightly. A well designed component should anticipate these modifications by providing hooks that allow users to extend or alter functionality without modifying the internal structure of the component.

There are several principles that help us create reusable components. Components should be general, abstract, and not too smart. (It's hard to replace components that know too much about the overall system.)

Components that depend on lots of other components are said to be encumbered. Encumbered components are also difficult to reuse since all the provider components must also be imported into the new system.

Other Principles

One can see the other major design principles such as the Abstraction Principle, Modularity Principle, and Open-Closed Principle as corollaries of the Reusability Principle.

Example: The Reusability Hierarchy

Software components can often be classified according to reusability levels:

Examples of foundation components are classes such as Money, Date, List, Person, and Number. These can be reused in almost any application and have very low encumbrance.

Examples of architecture-specific components include event notification mechanisms, user interfaces components, and message passing systems.

Examples of domain-specific components include classes like Customer, Account, and Transaction.

Examples of application-specific components include message handlers, exception handlers, and views.