Reuse/Release Equivalency Principle

This is first of the design principles which looks at the macro-designing part of software engineering. Macro, because it does not suggest technical solutions, but gives guidelines for practical granularity required for reusing software. Reuse/Release Equivalency Principle (REP) states:

The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused. This granule is the package.

Package can be considered to be the unit of distribution of the software. When I want to reuse a component, package is the concrete unit I am reusing. Package is not necessarily the preferred nomenclature, it is also called library, domain, functionality, or for that matter anything used to bind a set of classes together. For example, when I am using a file operations library, it is the unit of distribution and usage, even if I am using only the class for reading the file.

Releasing a package means an implicit signed contract, that this package will serve as specified. This contract serves as a guarantee that the package will abide by its interface and functionality. Also that the onus of maintaining the source is that of the author and not the user. This enforcement will lead to direct obedience of the Design By Contract (DBC) methodology.

Why not Classes?

It can be argued that classes themselves can be used for distribution and usage. However, if we follow the basic design principles, we will always endup with more than one class, which communicate with each other. If individual classes are released, the version tracking and compatibility might be a nightmare. So, the unit of release has to be something bigger than the class - which we call package. Hence, packages are the granular units of release and hence reuse even if classes can be the units of design.

The tracking system is important because the author owns the responsibility of upgrading the package that is being reused. Changes or enhancements in the package can be triggered by many factors, like new standards, new requirements, bugs or sometimes new methodologies and technologies. The author has to track the changes in the package along with maintaining its source code.

Next we will look at principles that guide compositions of the package.

Back to Design Principles.

Technorati tags: reuse release equivalency principle, rep, design principles, design by contract, object oriented