Software Reuse

Introduction

Given the desirable attributes attained by reusing software, it is important to define the concept concisely. This is especially true given the wide range of interpretations assigned to this seemingly self-explanatory pair of words.

Software reuse is concerned with the ability use a source code component in more than one context without changing the component.

Sounds simple enough, right? The problem comes with the "without change" restriction. Not only does this mean that the file containing the source code may not be changed, it also means that the file cannot be moved, copied, renamed or conditionally compiled.

This strict definition of software reuse is important so that we may achieve the promise of software reuse.

Namespace Changes

The act of moving or renaming a source file by definition affects the location of the file within the filesystem namespace. Such changes can force changes to dependent files. These dependent files include build environment files and other source files.

Build environment files include makefiles, environment variables, and build scripts that specify the location of files to be used within a project. For example, header include paths or paths specifying which source files need to be compiled for a given application.

Dependent source files may also be affected. For example if it is a header file whose name or location is being changed, all source files that include that header file must be modified to refer to the new location/name.

Moving files that have only one or two other dependent files is reasonably trivial. However, once a source code module has many dependents (a property that is highly desirable in a reuse environment),  moving or renaming a file becomes prohibitively time consuming. Thus, the organization of the source code repository is extremely important when reusing software.
 

Copying Files

Copying a source code module leads to increased  maintenance costs. If a defect is found and corrected in one of the copies, the change must be propagated to all of the other copies. The cost of this maintenance grows with the number of copies. Again, given the desirability of reusing a module as many times as possible, this scalability issue is quite important.

Unfortunately, copying a source file and using it in another context is a common practice within the software industry, that is frequently termed "software reuse". However, since this technique does not meet the standards defined here for software reuse, the terms "port" or "copy" will be used to refer to this technique.
 

Conditional Compilation

It is a time honored tradition, especially in the world of C/C++, to use the pre-processor's conditional compilation facilities as a means to reuse software. This is this yet another abuse of the C/C++ pre-processor. Aside from producing an unreadable rat's nest of code that very much affects the maintainability of the source code, it only results in the reuse of the file-name itself.

Like any tool, conditional compilation has its place. For example, as a mechanism for ensuring that a file is included only once for a given compilation unit. However, for the purposes of software reuse, conditional compilation is usually a sign that there is a need to examine the source code for abstraction opportunities. Typically, interfaces can be defined and the appropriate implementation used by the project at compile and link time rather than during pre-processing.

mike@mnmoran.org