CSC/ECE 517 Fall 2009/wiki3 16 teamhelm

The Release Reuse Equivalency Principle (REP)

Components can be effectively reused only if they are released through a tracking system.

Concept

The Release Reuse Equivalency Principle (REP), first introduced by Bertrand Meyer [3][4], and later laid down in details by Bob Martin, is described as follows:

"The granule of reuse is the granule of release."

Martin elaborates: "A reusable element, be it a component, a class, or a cluster of classes, cannot be reused unless it is managed by a release system of some kind. Users will be unwilling to use the element if they are forced to upgrade every time the author changes it. Thus. even though the author has released a new version of his reusable element, he must be willing to support and maintain older versions while his customers go about the slow business of getting ready to upgrade. Thus, clients will refuse to reuse an element unless the author promises to keep track of version numbers, and maintain old versions for awhile. Therefore, one criterion for grouping classes into packages is reuse. Since packages are the unit of release, they are also the unit of reuse. Therefore architects would do well to group reusable classes together into packages." [1]

Description

Martin describes a "release system" in his concept, which refers to a system that is able to track versions of code as it is changed. This is also sometimes referred to as version control. Some common examples of version control are SVN, CVS and CMVC.

Martin also states that customers are slow to upgrade newer versions of code. This is commonly true for several reasons, including fear of instability of software, internal process, management approvals, and downtime for software systems.

Another critical concept here is that Martin states clients will refuse to upgrade unless the author tracks version numbers. This is related to the previous concept, where a client or customer, because of the above factors, may need to revert the system to a previous version of the code because the new version has caused a problem or outage.

REP has also been described in the following way:

"..in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it." [2]

Further elaboration on REP is noted here:

"I reuse code if, and only if, I never need to look at the source code (other than the public portions of header files). I need only link with static libraries or include dynamic libraries. Whenever these libraries are fixed or enhanced, I receive a new version which I can then integrate into my system when opportunity allows. That is, I expect the code I am reusing to be treated like a product. It is not maintained by me. It is not distributed by me. I am the customer, and the author, or some other entity, is responsible for maintaining it. Thus, I can reuse nothing that is not also released. Moreover, when I reuse something in a released library, I am in effect a client of the entire library."[3]

In a nutshell, Martin is stating that reuse (not copying) is useless and meaningless without release. The concept of reuse is vital to elegant Object-Oriented design and therefore cannot be properly maintained without release.

Advantages

The obvious advantages of REP are:

1. Maintainability. There is no need to maintain reused code. This is done by the owner of the resused (released) code.
2. Flexibility. The consumer of the reused code can decide what version and on what timetable the reused code is adopted.
3. Enhancements. There is no need to make the reused code more efficient or to add function. New function can be added by upgrading to a new version of the reused code.

Disadvantages

As REP is a Cohesion Principle, the disadvantages would be similar to disadvantages of cohesion principles.

1. REP is not simple for the maintainer of the code. The code owner must maintain several versions of the code, as well as large packages.
2. The package structure cannot be designed from the top down, meaning that it would not be one of the first things about a system that is designed. Because of this, the package structure remains in a constant state of flux. [3]
3. The best design philosophy cannot depend solely on REP. REP is best suited for a system that has gone through the initial planning, design and development stages to ensure that the package structure can be utilized effectively.

Example

The Java Boutique desribes a tutorial for designing a system with, among other primciples, REP in mind.

A "bad" example of not following REP is to reuse code by copying the source code. Just a few days after Microsoft released its Windows 7 operating system, it had to apologize to the public for violating the GPL license.[5] A utility tool it hired the third party to develop contains a chunk of open source code with a GPL license attached to it. Microsoft had to endure the public humiliation and was "forced" to open its own source code for this utility program.

Conclusion

Code should be reused by including the released library, not by copying the code. This ensures the reused code is maintained by a single authority to avoid the divergence of the reused code. In fact the user should never see the source code for reuse except the included header files - The unit of reuse is the unit of release

The users of the library need to know the version for dependency control and for reliable reversal to the originals after failed upgrade. The author need the same information to maintain and support the released product - Effective reuse requires a change control system

Though a class is the de facto unit of reuse, its reuse is mostly confined to the author who also authors related classes and collectively make them a large functional unit - package. The REP is targeting a broad range of audience who are more interested in reuse this large functional unit or a class in that context. Also keeping track of version of individual classes would be burdensome to both the users who, more often than not, use multiple classes within the same package, and the author who need to maintain individual classes and their inter-dependencies within the large functional unit. The effective unit of reuse and release is the package

REP not only applies to external users, but also applies within the organization among different development groups.

References

[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
[2] Reuse Release Equivalence Principle: http://c2.com/cgi/wiki$?ReuseReleaseEquivalencePrinciple
[3] Granularity: http://www.objectmentor.com/resources/articles/granularity.pdf
[4] Object Oriented Software Construction, Bertrand Meyer, Prentice Hall, 1988