CSC/ECE 517 Fall 2009/wiki3 16 eit: Difference between revisions
No edit summary |
No edit summary |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
===Introduction=== | ===Introduction=== | ||
In several books and other writings, Bob Martin, also know in the Computer Science world as | In several books and other writings, Bob Martin, also know in the Computer Science world as [http://en.wikipedia.org/wiki/Uncle_Bob "Uncle Bob"], discuses several principals of object oriented design. According to Martin, his principals "expose the dependency management aspects of [http://en.wikipedia.org/wiki/Object-oriented_programming OOD] as opposed to the conceptualization and modeling aspects" [1]. That is, his principals help software engineers understand that there are dependencies that must be managed when using object oriented design. | ||
One of Martin’s principals is commonly referred to as the Reuse Release Equivalency Principal (REP). Martin’s REP states: | One of Martin’s principals is commonly referred to as the Reuse Release Equivalency Principal (REP). Martin’s REP states: | ||
"The granule of reuse is the granule of release. Only components that are release though a tracking system can be effectively resulted. This granule is the package." [2] | "The granule of reuse is the granule of release. Only components that are release though a tracking system can be effectively | ||
resulted. This granule is the package." [2] | |||
===Detailed Discussion of REP=== | ===Detailed Discussion of REP=== | ||
It is well know that one of the primary advantages of object oriented design is the ability to reuse code from one application in other applications that require the same functionality. In most languages, a class is used to represent a single | It is well know that one of the primary advantages of object oriented design is the ability to reuse code from one application in other applications that require the same functionality. In most [http://en.wikipedia.org/wiki/Programming_language languages], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class] is used to represent a single unit of functionality. Stephane Ducasse, et. al, further define classes to have two roles in object orient design. Ducasse, et. al. states that classes are primarily generators of instances, but are also units of reuse [3]. That is, classes are units of functionality that are designed to be portable. | ||
If it is accepted that the unit of reuse is the class then, according to Martin’s REP, the class must first be released though a formal control process before it can be reused. But why must it be released? Why can’t a software engineer simply copy and paste code from one program to another, or copy and paste snippets? While this may work in some cases, Martin suggests that this is not good practice. Martin discusses several reasons why. For example, if code is simply copied from one application to another, and a bug is found in the original code, the maintainer of the application the code was copied to must have a way to find this out. That maintainer must also make the same changes. However, if a class is tested, peer reviewed, documented, and maintained though a formal revision control process, it can be used as an | If it is accepted that the unit of reuse is the class then, according to Martin’s REP, the class must first be released though a formal control process before it can be reused. But why must it be released? Why can’t a software engineer simply copy and paste code from one program to another, or copy and paste snippets? While this may work in some cases, Martin suggests that this is not good practice. Martin discusses several reasons why. For example, if code is simply copied from one application to another, and a bug is found in the original code, the maintainer of the application the code was copied to must have a way to find this out. That maintainer must also make the same changes. However, if a class is tested, peer reviewed, documented, and maintained though a formal revision control process, it can be used as an "off the shelf" product in new applications. This "off the shelf" approach has several advantages according to Martin. The class can be treated as a “black box”; that is, the user does not need understand the inner workings of the class. The user may simply update the library module if fixes to the original code are made [2]. | ||
REP with Respect to Modern Version Control Systems | ===REP with Respect to Modern Version Control Systems=== | ||
With modern version control systems, it is relatively simply to baseline revision of code. Tools such as Subversion and CVS allow working, released, code to be copied and used in other projects. | With modern [http://en.wikipedia.org/wiki/Version_control_system version control systems], it is relatively simply to [http://en.wikipedia.org/wiki/Baseline_%28configuration_management%29 baseline] revision of code. Tools such as [http://en.wikipedia.org/wiki/Subversion_%28software%29 Subversion] and [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] allow working, released, code to be copied and used in other projects. | ||
REP with Respect to Agile Methodologies | ===REP with Respect to Agile Methodologies=== | ||
Agile software development methodologies are those that stress flexibility in the software’s requirements as the project progresses. These methods contrast methods such as the Waterfall Method witch stress design to a clear and well defined set of requirements. | [http://en.wikipedia.org/wiki/Agile_software Agile software] development methodologies are those that stress flexibility in the software’s requirements as the project progresses. These methods contrast methods such as the Waterfall Method witch stress design to a clear and well defined set of requirements. | ||
There are potential issues with REP when looked at against Agile Methodologies. For example if, during the course of an agile project, functionality is needed from a previously designed and released class, it can be used in the new application without violating REP. That is, the class and simply be checked out of the version control system | There are potential issues with REP when looked at against Agile Methodologies. For example if, during the course of an agile project, functionality is needed from a previously designed and released class, it can be used in the new application without violating REP. That is, the class and simply be checked out of the version control system using the established process and used in the new application. The REP would, in this case, appears to be well within one of the [http://agilemanifesto.org/principles.html Twelve Principals of Agile Software], “Continuous attention to technical excellence and good design enhances agility” [4]. | ||
However, Agile Methodologies all have the general philosophy of “get it working” in small chucks. One of the Twelve Principals of Agile Software states, Working software is the primary measure of progress” [4]. In this case, it is reasonable to think that one developer may write some code that is of use to another on the team. If this is the case, | However, Agile Methodologies all have the general philosophy of “get it working” in small chucks. One of the Twelve Principals of Agile Software states, "Working software is the primary measure of progress” [4]. In this case, it is reasonable to think that one developer may write some code that is of use to another on the team. If this is the case, the developers may be able to just be able to copy and paste the code and get a working piece of software. In this case, REP violates one of the Agile Software movement’s Twelve Principals. | ||
===References=== | ===References=== | ||
| Line 30: | Line 31: | ||
[3] Ducasse, Stéphane (University of Berne); Nierstrasz, Oscar; Schärli, Nathanael; Wuyts, Roel; Black, Andrew P. Source: ACM Transactions on Programming Languages and Systems, v 28, n 2, p 331-388, 2006 | [3] Ducasse, Stéphane (University of Berne); Nierstrasz, Oscar; Schärli, Nathanael; Wuyts, Roel; Black, Andrew P. Source: ACM Transactions on Programming Languages and Systems, v 28, n 2, p 331-388, 2006 | ||
[4] Beck, et. al, Principles behind the Agile Manifesto, Available at: http://agilemanifesto.org/principles.html | [4] Beck, et. al, Principles behind the Agile Manifesto, Available at: http://agilemanifesto.org/principles.html | ||
Latest revision as of 02:15, 24 November 2009
Reuse Release Equivalency Principal
Introduction
In several books and other writings, Bob Martin, also know in the Computer Science world as "Uncle Bob", discuses several principals of object oriented design. According to Martin, his principals "expose the dependency management aspects of OOD as opposed to the conceptualization and modeling aspects" [1]. That is, his principals help software engineers understand that there are dependencies that must be managed when using object oriented design.
One of Martin’s principals is commonly referred to as the Reuse Release Equivalency Principal (REP). Martin’s REP states:
"The granule of reuse is the granule of release. Only components that are release though a tracking system can be effectively resulted. This granule is the package." [2]
Detailed Discussion of REP
It is well know that one of the primary advantages of object oriented design is the ability to reuse code from one application in other applications that require the same functionality. In most languages, a class is used to represent a single unit of functionality. Stephane Ducasse, et. al, further define classes to have two roles in object orient design. Ducasse, et. al. states that classes are primarily generators of instances, but are also units of reuse [3]. That is, classes are units of functionality that are designed to be portable.
If it is accepted that the unit of reuse is the class then, according to Martin’s REP, the class must first be released though a formal control process before it can be reused. But why must it be released? Why can’t a software engineer simply copy and paste code from one program to another, or copy and paste snippets? While this may work in some cases, Martin suggests that this is not good practice. Martin discusses several reasons why. For example, if code is simply copied from one application to another, and a bug is found in the original code, the maintainer of the application the code was copied to must have a way to find this out. That maintainer must also make the same changes. However, if a class is tested, peer reviewed, documented, and maintained though a formal revision control process, it can be used as an "off the shelf" product in new applications. This "off the shelf" approach has several advantages according to Martin. The class can be treated as a “black box”; that is, the user does not need understand the inner workings of the class. The user may simply update the library module if fixes to the original code are made [2].
REP with Respect to Modern Version Control Systems
With modern version control systems, it is relatively simply to baseline revision of code. Tools such as Subversion and CVS allow working, released, code to be copied and used in other projects.
REP with Respect to Agile Methodologies
Agile software development methodologies are those that stress flexibility in the software’s requirements as the project progresses. These methods contrast methods such as the Waterfall Method witch stress design to a clear and well defined set of requirements.
There are potential issues with REP when looked at against Agile Methodologies. For example if, during the course of an agile project, functionality is needed from a previously designed and released class, it can be used in the new application without violating REP. That is, the class and simply be checked out of the version control system using the established process and used in the new application. The REP would, in this case, appears to be well within one of the Twelve Principals of Agile Software, “Continuous attention to technical excellence and good design enhances agility” [4].
However, Agile Methodologies all have the general philosophy of “get it working” in small chucks. One of the Twelve Principals of Agile Software states, "Working software is the primary measure of progress” [4]. In this case, it is reasonable to think that one developer may write some code that is of use to another on the team. If this is the case, the developers may be able to just be able to copy and paste the code and get a working piece of software. In this case, REP violates one of the Agile Software movement’s Twelve Principals.
References
[1] Object Oriented Design Principals, Available at: http://www.surfscranton.com/Architecture/ObjectOrientedDesignPrinciples.htm
[2] Martin, Robert C., Granularity, Available at: http://www.objectmentor.com/resources/articles/granularity.pdf
[3] Ducasse, Stéphane (University of Berne); Nierstrasz, Oscar; Schärli, Nathanael; Wuyts, Roel; Black, Andrew P. Source: ACM Transactions on Programming Languages and Systems, v 28, n 2, p 331-388, 2006
[4] Beck, et. al, Principles behind the Agile Manifesto, Available at: http://agilemanifesto.org/principles.html