CSC/ECE 517 Fall 2009/wiki3 teamhelm: Difference between revisions
Line 28: | Line 28: | ||
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. | 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. | |||
=='''''Advantages'''''== | =='''''Advantages'''''== |
Revision as of 15:48, 14 November 2009
The Release Reuse Equivalency Principle (REP)
Concept
The Release Reuse Equivalency Principle (REP), first introduced by Bob Martin, is described as follows:
"The granule of reuse is the granule of release."
"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.
Advantages
Disadvantages
Example
Conclusion
References
[1] Design Principles and Patterns: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf