CSC/ECE 517 Fall 2009/wiki3 16 aa

Reuse/Release Principle

The Reuse/Release Principle was coined by Robert C. Martin in C++ Report 1996 and states that “The granule of reuse is the granule of release. Only components that are released through a tracking system can effectively be reused. This granule is the package.” [1] This principle is one of several principles used in software design and development and is central to how packages should be built. Before attempting to understand the principle, a look at understanding the proper definition of code reuse is necessary.

Definition of Reuse

Code reuse takes on different meanings to different people. To some, reuse may be the simple idea of cutting code from one module and copying in another. To others, reuse is copying a compiled class into another project or application. Both of those examples are in fact undeveloped versions of code reuse. They are better explained as copying code rather than examples of proper reuse. Why? Reusable code is better defined as packaged modules capable of being used in multiple applications but having a single residence, owner, and maintainer. Both the owner and maintainer are entities that may consist of one or multiple people.

Requirements for Reuse

In order to effectively reuse code, several requirements should be met.

• Packages – Dependent classes or modules are placed into a package. Packages are the foundation for reuse. They provide a place for all dependencies to be grouped and released collectively. For example, for a Health Insurance Claims Workfile system the following classes can be separated into different packages as shown below:



Patient Information (org.name.patient)	Claim Information (org.name.claim)
Patient	Claim
Account	Status
Policy	Medium
Insurance	Representative


Since all of the above classes work collectively, it is better to pull them together into one package, like org.name.claimworkfile, so that all of the classes are released as a whole. There could still be two subpackages of org.name.patient and org.name.claim. So a possible package structure of the above classes could be:



• Claim Workfile (org.name.claimworkfile)
• Patient Information (org.name.patient)
• Patient
• Account
• Policy
• Insurance
• Claim Information (org.name.claim)
• Claim
• Status
• Medium
• Representative




• Release / Source Control – Packages should be placed under the governance of a source control or tracking system. The control system would manage the release of original packages as well as the enhanced versions. Each release would have a release or version number associated with it. Ideally clients or reusers would get notified before a release occurs so that they can plan and prioritize their schedule in order to incorporate the new package release.


• Documentation – Proper documentation must accompany each release. Without good release notes it is difficult for the client who uses the package to easily incorporate it into their own application.

Benefits of Reuse/Release Principle

The Reuse/Release Principle has several benefits for the client or reuser.

• Decreased Maintenance [2] – The client has less code that he must maintain himself.
• Improved Quality [2] - Since the client has less code to maintain, focus can be given to that which he does need to keep up. Also, the client does not have to be the only one to provide enhancements or new features to his application. As the supplier of the reused code periodically upgrades it, the client can take advantage of those upgrades without having to be the one who changed the code.
• Automated Builds [3] - Clients of reused code should take advantage of the tools that are available to automatically build their application from a storehouse of packages. That practice frees the developers from the IDE because their applications can be rebuilt outside of the IDE using a tool like ANT.
• Robust software [1] – Because the client does not have to develop every feature in his software from scratch, his software can include more features with much less effort or time for including those features.

Disadvantages of Reuse/Release Principle

Everything that has an advantage typically has a disadvantage. The same is true for the Reuse/Release Principle.

• Dependence on supplier – It is nice to be able to depend on the supplier for enhancements to a particular package of code. However, for the client it may be inconvenient at times and may possibly become a risk against meeting an implementation deadline. The client may need a bug fixed or an enhancement made to the reused package before their deliverable can be released. Yet, they are at the mercy of the supplier’s schedule as to when the update will be complete and ready for release.
• Pressure from clients – While the clients may have it easier in some regard, the suppliers may not. They may be placed under pressure and time constraints that are proposed by their clients. Clients expect for the reused code to be bug free. Timely upgrades are also expected so that the code is current with trends and technologies. Suppliers may therefore feel the pressure of those client wishes as they lobby for position in their busy schedules.

Links

1. Granularity
2. Object Reuse
3. Object Reuse Within the Enterprise: A Report From the Field