Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-24T02:45:40Z

Catowner: /* Software Design Anti-Patterns */

== Software Design Anti-Patterns ==

''Not all patterns are good. Anti-patterns are patterns that initially seem effective,''
''but over time you learn that they lead you into traps.''
- Scott Klement, ''[http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side]''

In this article, we will describe several software design patterns which have been categorized as "anti patterns": Programming approaches which are not uncommon and which can lead to poor program design and performance.

== What are Anti-Patterns? ==

Different texts define the term '''anti-patterns''' in different ways:
* ''"An AntiPatern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences."'' - '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis]'''
* ''"Anti-patterns are patterns that initially seem effective, but over time you learn that they lead you into traps."'' - [http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side]
* Over the last decade we have witnessed the maturity of both best practices...and worst practices (as manifested in the anti-patterns movement...). - [http://www.jot.fm/issues/issue_2006_07/column4.pdf Patterns of Anti-Patterns?], Journal of Object Technology

In each definition, the implementer of the anti-pattern is trying to solve a problem in a common way, however the common way is a bad design that can lead to unintended consequences. Some of the reasons cited in the '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns]''' book as to why these anti-patterns have been used include: Haste, sloth (or laziness), ignorance, apathy, and pride. Studying anti-patterns can at least help assist the potential anti-pattern implementer in the ignorance category.

== Considerations When Writing Anti-Patterns ==

When writing patterns, there are various templates to from which to choose, for example, the pattern template from the Gang of Four's Design Pattern book:

* Pattern Name and Classification
* Intent
* Also Known As
* Motivation
* Applicability
* Structure
* Participants
* Collaboration
* Consequences
* Implementation
* Sample Code
* Known Uses
* Related Patterns

Brown et al in their book [http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns] suggest 3 different possible templates for writing anti-patterns:
* Pseudo-AntiPattern Template: Only the name and problem are described
* Mini-AntiPattern Template: Includes the name, AntiPattern Problems, and Refactored Solution
* Full AntiPattern Template: Includes 18 different sections such as Root Causes, Background, Known Exceptions, and Examples.

For the purposes of brevity, this wiki page will use the Mini-AntiPattern Template form with the addition of an Example section.

== Anti-Pattern Examples ==

This section presents six anti-patterns from the book '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis]'''.

=== The Blob ''or'' God Class ===

==== Anti-Pattern Problem ====
A design includes a class that has the majority of attributes and/or methods in the system. According to Brown et al, this anti-pattern could be the result of using a procedural design in an object-oriented language, and therefore imbuing one of the classes with the majority of the methods and seeing that class as a "controller" class. Another sign that the Blob anti-pattern may be present is if a class is designated as a "utility" class, which indicates a possible catch-all class for unrelated classes.

==== Refactored Solution ====
Brown et al suggests refactoring responsibilities into appropriate classes using the following steps:
* Identify cohesive sets of operations and attributes that relate to a common focus, behavior, or function.
* Review the system to see if there are "natural homes" for these collections in existing classes.
* Remove redundant or "far-coupled" associations.
* Migrate associates to derived classes to a common base class.
* Remove all transient associations, replacing them as appropriate with type specifiers to attributes and operations arguments.

==== Example ====
An inappropriate use of the Rails framework, where a majority of the methods reside in a single controller class or model class. To resolve the issues, helper classes or other classes could be created which would more appropriately contain related methods that were inappropriately kept in a controller or model.

=== Lava Flow ===

==== Anti-Pattern Problem ====
A design includes obsolete technologies or unused or misunderstood extensions. This problem usually occurs when prototype or research code is used as the basis for a production system, or when a code base has existed over a long period of time and the code base was not updated to reflect changes in surrounding technologies or systems.

==== Refactored Solution ====
Often times, the presence of obsolete or unused code is the result of lacking a sound design and architecture that is followed and updated throughout the system lifecycle. To resolve the issue of obsolete code, a redefinition of the architecture is necessary, with removal of "dead" code as the system is refactored to the new architecture. There is no easy fix for this issue, and it will take time to reengineer the system to remove redundancy and obsolescence.

==== Example ====
A financial program that helps customers manage their stock portfolio was developed as a web application with using HTML 2.0 and Java 1.3 servlets. Over time, the program was enhanced by building on the existing code base. Eventually the system was upgraded to serving XHTML 5 pages and using Java 6 in the server. Because of the lack of comprehensive design and architectural documentation, portions of the code use depracated methods and badly formatted HTML in places because the current development team does not understand the system to know what is "safe" to change or remove.

=== Poltergeists or Gypsy ===

==== Anti-Pattern Problem ====
A design which includes classes that have minimal responsibilities and roles in the system. These "poltergeists" appear only briefly in the system, possibly to invoke methods of other classes. Brown et al indicates these classes are usually a sign of an inexperienced OO developer who has overdesigned the system.

==== Refactored Solution ====
Simply removed the "poltergeists" from the system altogether and then move the functionality to a related class.

==== Example ====
A developer is writing the software for an automated label printing system. He decides to create a SystemController class which drives all the actions within the system (move label to printer, extract label information from database, print label, eject printed label). Other than directing the actions of the other classes, the SystemController has no other purpose, and is effectively a "poltergeist". In this situation, an object-oriented design may not even be warranted, and a procedural design may be more appropriate.

=== Golden Hammer ===

==== Anti-Pattern Problem ====
A system overuses a solution or vendor product to the detriment of the design and system itself. This can occur if a developer or development team has gotten comfortable with an approach or technology, and keeps going back to that approach or technology as the answer to all problems. Additionally, a development team may find itself forced into that situation for business reasons if their company has invested heavily in a product or technology and is expecting a return on that investment.

==== Refactored Solution ====
The refactoring for this anti-pattern involves a change in mindset as well as a software changes. The development team must acknowledge the appropriate use and limitations of the "favored" technology. Other approaches should be investigated and weighed fairly against each other. Where investments are involved, management may be needed to step in to make sure that technology investments are more evenly distributed.

==== Example ====
A developer new to Ruby on Rails needs to create a new data structure. Having created several models which also create new database tables, the developer defaults to creating another model which adds a new table to the database. This approach is not recommended for transient data when instead a simple class with attributes would suffice.

=== Spaghetti Code ===

==== Anti-Pattern Problem ====
A system appears to have little software structure. This type of anti-pattern can result when developers code first, and then possibly attempt to design along the way. The code with this issue is often difficult to understand, maintain, or enhance. The system is very closed and does not lend itself to reuse.

==== Refactored Solution ====
The solution in this case is to perform a major refactoring or clean-up on the system. Initially the goal should be to achieve an overall structure that is sensible, and then move toward improving performance and internal structures.

==== Example ====
A development team quickly creates a working prototype of a grade book, and are then pushed to provide a production version within 2 months. The working prototype actually has 80% of the function available, so the team works from that base to complete the production version. In the process of creating the prototype, the team gave little thought to design and extensibility, and they had no time when creating the production version to produce a product that could be easily extended.

=== Cut-and-Paste Programming ===

==== Anti-Pattern Problem ====
An implementation contains "cloned" code throughout the project. A developer needs to solve a particular problem in his code which has already been implemented in a different section of code. He finds he can quickly gain the new function by just copying the original code to the new location. Problems occur when unknown bugs in the original code are replicated to the new code. Further, it is more difficult to enhance the code because one must know multiple places to make changes.

==== Refactored Solution ====
Cloned code can be refactored either through use of a common method or through inheritance. Additionally, going forward, a development team can attempt to identify likely code which should be usable, and they can design the code to exist in a reusable method or class.

==== Example ====
A developer is attempting to solve an issue in his section of the code which he knows has been solved in another area. He finds that he can quickly copy the foreign code into his code and resolve his issue. He knows that he could create a common method or class that he and the other code section could use, but he chooses not to do that because of the coordination with other developers that would be involved.

== Conclusion ==

Reviewing anti-patterns can be very beneficial to help you avoid the common pitfalls that inexperienced (and sometimes experienced) software developers fall in when writing software. Besides identifying design issues, anti-patterns can also give insight into the group dysfunction and business realities that also influence the production of software. Just as design patterns offer a shortcut for architects and developers in talking about implementation, anti-patterns can also offer a shortcut for describing issues to developers and others. Knowing about anti-patterns can also offer some comfort when the inevitable mistakes are made.

== References ==

* [http://www.antipatterns.com/ www.antipatterns.com]
* W. J. Brown et al., [http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis], John Wiley & Sons, Inc., New York, NY, 1998.
* S. Klement, [http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side], 2008
* Wikipedia entry: [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://c2.com/cgi/wiki?AntiPatternsCatalog Anti Patterns Catalog] offered by Cunningham & Cunningham, Inc.
* [http://sourcemaking.com/antipatterns What is an AntiPattern?] from Sourcemaking.com
* [http://www.lostechies.com/blogs/chrismissal/archive/2009/05/25/anti-patterns-and-worst-practices-you-re-doing-it-wrong.aspx Anti-Patterns and Worst Practices – You’re Doing it Wrong!]
* M. H. Dodani,[http://www.jot.fm/issues/issue_2006_07/column4.pdf Patterns of Anti-Patterns?], Journal of Object Technology, Vol 5, No 6, pp 29-33, 2006
* E. Gamma et al,[http://www.amazon.com/dp/0201633612 Design Patterns: Elements of Reusable Object-Oriented Software], Addison-Wesley Professional, 1994.
* G. Meszaros and J. Doble, [http://hillside.net/patterns/writing/patternwritingpaper.htm A Pattern Language for Pattern Writing].

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-24T02:44:03Z

Catowner: /* Poltergeists or Gypsy */

== Software Design Anti-Patterns ==

''Not all patterns are good. Anti-patterns are patterns that initially seem effective, but over time you learn that they lead you into traps.''
- Scott Klement, ''[http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side]''

In this article, we will describe several software design patterns which have been categorized as "anti patterns": Programming approaches which are not uncommon and which can lead to poor program design and performance.

== What are Anti-Patterns? ==

Different texts define the term '''anti-patterns''' in different ways:
* ''"An AntiPatern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences."'' - '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis]'''
* ''"Anti-patterns are patterns that initially seem effective, but over time you learn that they lead you into traps."'' - [http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side]
* Over the last decade we have witnessed the maturity of both best practices...and worst practices (as manifested in the anti-patterns movement...). - [http://www.jot.fm/issues/issue_2006_07/column4.pdf Patterns of Anti-Patterns?], Journal of Object Technology

In each definition, the implementer of the anti-pattern is trying to solve a problem in a common way, however the common way is a bad design that can lead to unintended consequences. Some of the reasons cited in the '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns]''' book as to why these anti-patterns have been used include: Haste, sloth (or laziness), ignorance, apathy, and pride. Studying anti-patterns can at least help assist the potential anti-pattern implementer in the ignorance category.

== Considerations When Writing Anti-Patterns ==

When writing patterns, there are various templates to from which to choose, for example, the pattern template from the Gang of Four's Design Pattern book:

* Pattern Name and Classification
* Intent
* Also Known As
* Motivation
* Applicability
* Structure
* Participants
* Collaboration
* Consequences
* Implementation
* Sample Code
* Known Uses
* Related Patterns

Brown et al in their book [http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns] suggest 3 different possible templates for writing anti-patterns:
* Pseudo-AntiPattern Template: Only the name and problem are described
* Mini-AntiPattern Template: Includes the name, AntiPattern Problems, and Refactored Solution
* Full AntiPattern Template: Includes 18 different sections such as Root Causes, Background, Known Exceptions, and Examples.

For the purposes of brevity, this wiki page will use the Mini-AntiPattern Template form with the addition of an Example section.

== Anti-Pattern Examples ==

This section presents six anti-patterns from the book '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis]'''.

=== The Blob ''or'' God Class ===

==== Anti-Pattern Problem ====
A design includes a class that has the majority of attributes and/or methods in the system. According to Brown et al, this anti-pattern could be the result of using a procedural design in an object-oriented language, and therefore imbuing one of the classes with the majority of the methods and seeing that class as a "controller" class. Another sign that the Blob anti-pattern may be present is if a class is designated as a "utility" class, which indicates a possible catch-all class for unrelated classes.

==== Refactored Solution ====
Brown et al suggests refactoring responsibilities into appropriate classes using the following steps:
* Identify cohesive sets of operations and attributes that relate to a common focus, behavior, or function.
* Review the system to see if there are "natural homes" for these collections in existing classes.
* Remove redundant or "far-coupled" associations.
* Migrate associates to derived classes to a common base class.
* Remove all transient associations, replacing them as appropriate with type specifiers to attributes and operations arguments.

==== Example ====
An inappropriate use of the Rails framework, where a majority of the methods reside in a single controller class or model class. To resolve the issues, helper classes or other classes could be created which would more appropriately contain related methods that were inappropriately kept in a controller or model.

=== Lava Flow ===

==== Anti-Pattern Problem ====
A design includes obsolete technologies or unused or misunderstood extensions. This problem usually occurs when prototype or research code is used as the basis for a production system, or when a code base has existed over a long period of time and the code base was not updated to reflect changes in surrounding technologies or systems.

==== Refactored Solution ====
Often times, the presence of obsolete or unused code is the result of lacking a sound design and architecture that is followed and updated throughout the system lifecycle. To resolve the issue of obsolete code, a redefinition of the architecture is necessary, with removal of "dead" code as the system is refactored to the new architecture. There is no easy fix for this issue, and it will take time to reengineer the system to remove redundancy and obsolescence.

==== Example ====
A financial program that helps customers manage their stock portfolio was developed as a web application with using HTML 2.0 and Java 1.3 servlets. Over time, the program was enhanced by building on the existing code base. Eventually the system was upgraded to serving XHTML 5 pages and using Java 6 in the server. Because of the lack of comprehensive design and architectural documentation, portions of the code use depracated methods and badly formatted HTML in places because the current development team does not understand the system to know what is "safe" to change or remove.

=== Poltergeists or Gypsy ===

==== Anti-Pattern Problem ====
A design which includes classes that have minimal responsibilities and roles in the system. These "poltergeists" appear only briefly in the system, possibly to invoke methods of other classes. Brown et al indicates these classes are usually a sign of an inexperienced OO developer who has overdesigned the system.

==== Refactored Solution ====
Simply removed the "poltergeists" from the system altogether and then move the functionality to a related class.

==== Example ====
A developer is writing the software for an automated label printing system. He decides to create a SystemController class which drives all the actions within the system (move label to printer, extract label information from database, print label, eject printed label). Other than directing the actions of the other classes, the SystemController has no other purpose, and is effectively a "poltergeist". In this situation, an object-oriented design may not even be warranted, and a procedural design may be more appropriate.

=== Golden Hammer ===

==== Anti-Pattern Problem ====
A system overuses a solution or vendor product to the detriment of the design and system itself. This can occur if a developer or development team has gotten comfortable with an approach or technology, and keeps going back to that approach or technology as the answer to all problems. Additionally, a development team may find itself forced into that situation for business reasons if their company has invested heavily in a product or technology and is expecting a return on that investment.

==== Refactored Solution ====
The refactoring for this anti-pattern involves a change in mindset as well as a software changes. The development team must acknowledge the appropriate use and limitations of the "favored" technology. Other approaches should be investigated and weighed fairly against each other. Where investments are involved, management may be needed to step in to make sure that technology investments are more evenly distributed.

==== Example ====
A developer new to Ruby on Rails needs to create a new data structure. Having created several models which also create new database tables, the developer defaults to creating another model which adds a new table to the database. This approach is not recommended for transient data when instead a simple class with attributes would suffice.

=== Spaghetti Code ===

==== Anti-Pattern Problem ====
A system appears to have little software structure. This type of anti-pattern can result when developers code first, and then possibly attempt to design along the way. The code with this issue is often difficult to understand, maintain, or enhance. The system is very closed and does not lend itself to reuse.

==== Refactored Solution ====
The solution in this case is to perform a major refactoring or clean-up on the system. Initially the goal should be to achieve an overall structure that is sensible, and then move toward improving performance and internal structures.

==== Example ====
A development team quickly creates a working prototype of a grade book, and are then pushed to provide a production version within 2 months. The working prototype actually has 80% of the function available, so the team works from that base to complete the production version. In the process of creating the prototype, the team gave little thought to design and extensibility, and they had no time when creating the production version to produce a product that could be easily extended.

=== Cut-and-Paste Programming ===

==== Anti-Pattern Problem ====
An implementation contains "cloned" code throughout the project. A developer needs to solve a particular problem in his code which has already been implemented in a different section of code. He finds he can quickly gain the new function by just copying the original code to the new location. Problems occur when unknown bugs in the original code are replicated to the new code. Further, it is more difficult to enhance the code because one must know multiple places to make changes.

==== Refactored Solution ====
Cloned code can be refactored either through use of a common method or through inheritance. Additionally, going forward, a development team can attempt to identify likely code which should be usable, and they can design the code to exist in a reusable method or class.

==== Example ====
A developer is attempting to solve an issue in his section of the code which he knows has been solved in another area. He finds that he can quickly copy the foreign code into his code and resolve his issue. He knows that he could create a common method or class that he and the other code section could use, but he chooses not to do that because of the coordination with other developers that would be involved.

== Conclusion ==

Reviewing anti-patterns can be very beneficial to help you avoid the common pitfalls that inexperienced (and sometimes experienced) software developers fall in when writing software. Besides identifying design issues, anti-patterns can also give insight into the group dysfunction and business realities that also influence the production of software. Just as design patterns offer a shortcut for architects and developers in talking about implementation, anti-patterns can also offer a shortcut for describing issues to developers and others. Knowing about anti-patterns can also offer some comfort when the inevitable mistakes are made.

== References ==

* [http://www.antipatterns.com/ www.antipatterns.com]
* W. J. Brown et al., [http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis], John Wiley & Sons, Inc., New York, NY, 1998.
* S. Klement, [http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side], 2008
* Wikipedia entry: [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://c2.com/cgi/wiki?AntiPatternsCatalog Anti Patterns Catalog] offered by Cunningham & Cunningham, Inc.
* [http://sourcemaking.com/antipatterns What is an AntiPattern?] from Sourcemaking.com
* [http://www.lostechies.com/blogs/chrismissal/archive/2009/05/25/anti-patterns-and-worst-practices-you-re-doing-it-wrong.aspx Anti-Patterns and Worst Practices – You’re Doing it Wrong!]
* M. H. Dodani,[http://www.jot.fm/issues/issue_2006_07/column4.pdf Patterns of Anti-Patterns?], Journal of Object Technology, Vol 5, No 6, pp 29-33, 2006
* E. Gamma et al,[http://www.amazon.com/dp/0201633612 Design Patterns: Elements of Reusable Object-Oriented Software], Addison-Wesley Professional, 1994.
* G. Meszaros and J. Doble, [http://hillside.net/patterns/writing/patternwritingpaper.htm A Pattern Language for Pattern Writing].

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-24T02:41:25Z

Catowner: /* Poltergeists or Gypsy */

== Software Design Anti-Patterns ==

''Not all patterns are good. Anti-patterns are patterns that initially seem effective, but over time you learn that they lead you into traps.''
- Scott Klement, ''[http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side]''

In this article, we will describe several software design patterns which have been categorized as "anti patterns": Programming approaches which are not uncommon and which can lead to poor program design and performance.

== What are Anti-Patterns? ==

Different texts define the term '''anti-patterns''' in different ways:
* ''"An AntiPatern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences."'' - '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis]'''
* ''"Anti-patterns are patterns that initially seem effective, but over time you learn that they lead you into traps."'' - [http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side]
* Over the last decade we have witnessed the maturity of both best practices...and worst practices (as manifested in the anti-patterns movement...). - [http://www.jot.fm/issues/issue_2006_07/column4.pdf Patterns of Anti-Patterns?], Journal of Object Technology

In each definition, the implementer of the anti-pattern is trying to solve a problem in a common way, however the common way is a bad design that can lead to unintended consequences. Some of the reasons cited in the '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns]''' book as to why these anti-patterns have been used include: Haste, sloth (or laziness), ignorance, apathy, and pride. Studying anti-patterns can at least help assist the potential anti-pattern implementer in the ignorance category.

== Considerations When Writing Anti-Patterns ==

When writing patterns, there are various templates to from which to choose, for example, the pattern template from the Gang of Four's Design Pattern book:

* Pattern Name and Classification
* Intent
* Also Known As
* Motivation
* Applicability
* Structure
* Participants
* Collaboration
* Consequences
* Implementation
* Sample Code
* Known Uses
* Related Patterns

Brown et al in their book [http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns] suggest 3 different possible templates for writing anti-patterns:
* Pseudo-AntiPattern Template: Only the name and problem are described
* Mini-AntiPattern Template: Includes the name, AntiPattern Problems, and Refactored Solution
* Full AntiPattern Template: Includes 18 different sections such as Root Causes, Background, Known Exceptions, and Examples.

For the purposes of brevity, this wiki page will use the Mini-AntiPattern Template form with the addition of an Example section.

== Anti-Pattern Examples ==

This section presents six anti-patterns from the book '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis]'''.

=== The Blob ''or'' God Class ===

==== Anti-Pattern Problem ====
A design includes a class that has the majority of attributes and/or methods in the system. According to Brown et al, this anti-pattern could be the result of using a procedural design in an object-oriented language, and therefore imbuing one of the classes with the majority of the methods and seeing that class as a "controller" class. Another sign that the Blob anti-pattern may be present is if a class is designated as a "utility" class, which indicates a possible catch-all class for unrelated classes.

==== Refactored Solution ====
Brown et al suggests refactoring responsibilities into appropriate classes using the following steps:
* Identify cohesive sets of operations and attributes that relate to a common focus, behavior, or function.
* Review the system to see if there are "natural homes" for these collections in existing classes.
* Remove redundant or "far-coupled" associations.
* Migrate associates to derived classes to a common base class.
* Remove all transient associations, replacing them as appropriate with type specifiers to attributes and operations arguments.

==== Example ====
An inappropriate use of the Rails framework, where a majority of the methods reside in a single controller class or model class. To resolve the issues, helper classes or other classes could be created which would more appropriately contain related methods that were inappropriately kept in a controller or model.

=== Lava Flow ===

==== Anti-Pattern Problem ====
A design includes obsolete technologies or unused or misunderstood extensions. This problem usually occurs when prototype or research code is used as the basis for a production system, or when a code base has existed over a long period of time and the code base was not updated to reflect changes in surrounding technologies or systems.

==== Refactored Solution ====
Often times, the presence of obsolete or unused code is the result of lacking a sound design and architecture that is followed and updated throughout the system lifecycle. To resolve the issue of obsolete code, a redefinition of the architecture is necessary, with removal of "dead" code as the system is refactored to the new architecture. There is no easy fix for this issue, and it will take time to reengineer the system to remove redundancy and obsolescence.

==== Example ====
A financial program that helps customers manage their stock portfolio was developed as a web application with using HTML 2.0 and Java 1.3 servlets. Over time, the program was enhanced by building on the existing code base. Eventually the system was upgraded to serving XHTML 5 pages and using Java 6 in the server. Because of the lack of comprehensive design and architectural documentation, portions of the code use depracated methods and badly formatted HTML in places because the current development team does not understand the system to know what is "safe" to change or remove.

=== Poltergeists or Gypsy ===

==== Anti-Pattern Problem ====
A design which includes classes that have minimal responsibilities and roles in the system. These "poltergeists" appear only briefly in the system, possibly to invoke methods of other classes. Brown et al indicates these classes are usually a sign of an inexperienced OO developer who has overdesigned the system.

==== Refactored Solution ====
Simply removed the "poltergeists" from the system altogether and then move the functionality to a related class.

==== Example ====
A developer is writing the software for an automated label printing system. He decides to create a SystemController class which drives all the actions within the system (move label to printer, extract label information from database, print label, eject printed label). Other than directing the actions of the other classes, the SystemController has no other purpose, and is effectively a "poltergeist".

=== Golden Hammer ===

==== Anti-Pattern Problem ====
A system overuses a solution or vendor product to the detriment of the design and system itself. This can occur if a developer or development team has gotten comfortable with an approach or technology, and keeps going back to that approach or technology as the answer to all problems. Additionally, a development team may find itself forced into that situation for business reasons if their company has invested heavily in a product or technology and is expecting a return on that investment.

==== Refactored Solution ====
The refactoring for this anti-pattern involves a change in mindset as well as a software changes. The development team must acknowledge the appropriate use and limitations of the "favored" technology. Other approaches should be investigated and weighed fairly against each other. Where investments are involved, management may be needed to step in to make sure that technology investments are more evenly distributed.

==== Example ====
A developer new to Ruby on Rails needs to create a new data structure. Having created several models which also create new database tables, the developer defaults to creating another model which adds a new table to the database. This approach is not recommended for transient data when instead a simple class with attributes would suffice.

=== Spaghetti Code ===

==== Anti-Pattern Problem ====
A system appears to have little software structure. This type of anti-pattern can result when developers code first, and then possibly attempt to design along the way. The code with this issue is often difficult to understand, maintain, or enhance. The system is very closed and does not lend itself to reuse.

==== Refactored Solution ====
The solution in this case is to perform a major refactoring or clean-up on the system. Initially the goal should be to achieve an overall structure that is sensible, and then move toward improving performance and internal structures.

==== Example ====
A development team quickly creates a working prototype of a grade book, and are then pushed to provide a production version within 2 months. The working prototype actually has 80% of the function available, so the team works from that base to complete the production version. In the process of creating the prototype, the team gave little thought to design and extensibility, and they had no time when creating the production version to produce a product that could be easily extended.

=== Cut-and-Paste Programming ===

==== Anti-Pattern Problem ====
An implementation contains "cloned" code throughout the project. A developer needs to solve a particular problem in his code which has already been implemented in a different section of code. He finds he can quickly gain the new function by just copying the original code to the new location. Problems occur when unknown bugs in the original code are replicated to the new code. Further, it is more difficult to enhance the code because one must know multiple places to make changes.

==== Refactored Solution ====
Cloned code can be refactored either through use of a common method or through inheritance. Additionally, going forward, a development team can attempt to identify likely code which should be usable, and they can design the code to exist in a reusable method or class.

==== Example ====
A developer is attempting to solve an issue in his section of the code which he knows has been solved in another area. He finds that he can quickly copy the foreign code into his code and resolve his issue. He knows that he could create a common method or class that he and the other code section could use, but he chooses not to do that because of the coordination with other developers that would be involved.

== Conclusion ==

Reviewing anti-patterns can be very beneficial to help you avoid the common pitfalls that inexperienced (and sometimes experienced) software developers fall in when writing software. Besides identifying design issues, anti-patterns can also give insight into the group dysfunction and business realities that also influence the production of software. Just as design patterns offer a shortcut for architects and developers in talking about implementation, anti-patterns can also offer a shortcut for describing issues to developers and others. Knowing about anti-patterns can also offer some comfort when the inevitable mistakes are made.

== References ==

* [http://www.antipatterns.com/ www.antipatterns.com]
* W. J. Brown et al., [http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis], John Wiley & Sons, Inc., New York, NY, 1998.
* S. Klement, [http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side], 2008
* Wikipedia entry: [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://c2.com/cgi/wiki?AntiPatternsCatalog Anti Patterns Catalog] offered by Cunningham & Cunningham, Inc.
* [http://sourcemaking.com/antipatterns What is an AntiPattern?] from Sourcemaking.com
* [http://www.lostechies.com/blogs/chrismissal/archive/2009/05/25/anti-patterns-and-worst-practices-you-re-doing-it-wrong.aspx Anti-Patterns and Worst Practices – You’re Doing it Wrong!]
* M. H. Dodani,[http://www.jot.fm/issues/issue_2006_07/column4.pdf Patterns of Anti-Patterns?], Journal of Object Technology, Vol 5, No 6, pp 29-33, 2006
* E. Gamma et al,[http://www.amazon.com/dp/0201633612 Design Patterns: Elements of Reusable Object-Oriented Software], Addison-Wesley Professional, 1994.
* G. Meszaros and J. Doble, [http://hillside.net/patterns/writing/patternwritingpaper.htm A Pattern Language for Pattern Writing].

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-18T02:23:18Z

Catowner: /* Conclusion */

== Software Design Anti-Patterns ==

''Not all patterns are good. Anti-patterns are patterns that initially seem effective, but over time you learn that they lead you into traps.''
- Scott Klement, ''[http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side]''

In this article, we will describe several software design patterns which have been categorized as "anti patterns": Programming approaches which are not uncommon and which can lead to poor program design and performance.

== What are Anti-Patterns? ==

Different texts define the term '''anti-patterns''' in different ways:
* ''"An AntiPatern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences."'' - '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis]'''
* ''"Anti-patterns are patterns that initially seem effective, but over time you learn that they lead you into traps."'' - [http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side]
* Over the last decade we have witnessed the maturity of both best practices...and worst practices (as manifested in the anti-patterns movement...). - [http://www.jot.fm/issues/issue_2006_07/column4.pdf Patterns of Anti-Patterns?], Journal of Object Technology

In each definition, the implementer of the anti-pattern is trying to solve a problem in a common way, however the common way is a bad design that can lead to unintended consequences. Some of the reasons cited in the '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns]''' book as to why these anti-patterns have been used include: Haste, sloth (or laziness), ignorance, apathy, and pride. Studying anti-patterns can at least help assist the potential anti-pattern implementer in the ignorance category.

== Considerations When Writing Anti-Patterns ==

When writing patterns, there are various templates to from which to choose, for example, the pattern template from the Gang of Four's Design Pattern book:

* Pattern Name and Classification
* Intent
* Also Known As
* Motivation
* Applicability
* Structure
* Participants
* Collaboration
* Consequences
* Implementation
* Sample Code
* Known Uses
* Related Patterns

Brown et al in their book [http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns] suggest 3 different possible templates for writing anti-patterns:
* Pseudo-AntiPattern Template: Only the name and problem are described
* Mini-AntiPattern Template: Includes the name, AntiPattern Problems, and Refactored Solution
* Full AntiPattern Template: Includes 18 different sections such as Root Causes, Background, Known Exceptions, and Examples.

For the purposes of brevity, this wiki page will use the Mini-AntiPattern Template form with the addition of an Example section.

== Anti-Pattern Examples ==

This section presents six anti-patterns from the book '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis]'''.

=== The Blob ''or'' God Class ===

==== Anti-Pattern Problem ====
A design includes a class that has the majority of attributes and/or methods in the system. According to Brown et al, this anti-pattern could be the result of using a procedural design in an object-oriented language, and therefore imbuing one of the classes with the majority of the methods and seeing that class as a "controller" class. Another sign that the Blob anti-pattern may be present is if a class is designated as a "utility" class, which indicates a possible catch-all class for unrelated classes.

==== Refactored Solution ====
Brown et al suggests refactoring responsibilities into appropriate classes using the following steps:
* Identify cohesive sets of operations and attributes that relate to a common focus, behavior, or function.
* Review the system to see if there are "natural homes" for these collections in existing classes.
* Remove redundant or "far-coupled" associations.
* Migrate associates to derived classes to a common base class.
* Remove all transient associations, replacing them as appropriate with type specifiers to attributes and operations arguments.

==== Example ====
An inappropriate use of the Rails framework, where a majority of the methods reside in a single controller class or model class. To resolve the issues, helper classes or other classes could be created which would more appropriately contain related methods that were inappropriately kept in a controller or model.

=== Lava Flow ===

==== Anti-Pattern Problem ====
A design includes obsolete technologies or unused or misunderstood extensions. This problem usually occurs when prototype or research code is used as the basis for a production system, or when a code base has existed over a long period of time and the code base was not updated to reflect changes in surrounding technologies or systems.

==== Refactored Solution ====
Often times, the presence of obsolete or unused code is the result of lacking a sound design and architecture that is followed and updated throughout the system lifecycle. To resolve the issue of obsolete code, a redefinition of the architecture is necessary, with removal of "dead" code as the system is refactored to the new architecture. There is no easy fix for this issue, and it will take time to reengineer the system to remove redundancy and obsolescence.

==== Example ====
A financial program that helps customers manage their stock portfolio was developed as a web application with using HTML 2.0 and Java 1.3 servlets. Over time, the program was enhanced by building on the existing code base. Eventually the system was upgraded to serving XHTML 5 pages and using Java 6 in the server. Because of the lack of comprehensive design and architectural documentation, portions of the code use depracated methods and badly formatted HTML in places because the current development team does not understand the system to know what is "safe" to change or remove.

=== Poltergeists or Gypsy ===

==== Anti-Pattern Problem ====
A design which includes classes that have minimal responsibilities and roles in the system. These "poltergeists" appear only briefly in the system, possibly to invoke methods of other classes. Brown et al indicates these classes are usually a sign of an inexperience OO developer who has overdesigned the system.

==== Refactored Solution ====
Simply removed the "poltergeists" from the system altogether and then move the functionality to a related class.

==== Example ====
TBD

=== Golden Hammer ===

==== Anti-Pattern Problem ====
A system overuses a solution or vendor product to the detriment of the design and system itself. This can occur if a developer or development team has gotten comfortable with an approach or technology, and keeps going back to that approach or technology as the answer to all problems. Additionally, a development team may find itself forced into that situation for business reasons if their company has invested heavily in a product or technology and is expecting a return on that investment.

==== Refactored Solution ====
The refactoring for this anti-pattern involves a change in mindset as well as a software changes. The development team must acknowledge the appropriate use and limitations of the "favored" technology. Other approaches should be investigated and weighed fairly against each other. Where investments are involved, management may be needed to step in to make sure that technology investments are more evenly distributed.

==== Example ====
A developer new to Ruby on Rails needs to create a new data structure. Having created several models which also create new database tables, the developer defaults to creating another model which adds a new table to the database. This approach is not recommended for transient data when instead a simple class with attributes would suffice.

=== Spaghetti Code ===

==== Anti-Pattern Problem ====
A system appears to have little software structure. This type of anti-pattern can result when developers code first, and then possibly attempt to design along the way. The code with this issue is often difficult to understand, maintain, or enhance. The system is very closed and does not lend itself to reuse.

==== Refactored Solution ====
The solution in this case is to perform a major refactoring or clean-up on the system. Initially the goal should be to achieve an overall structure that is sensible, and then move toward improving performance and internal structures.

==== Example ====
A development team quickly creates a working prototype of a grade book, and are then pushed to provide a production version within 2 months. The working prototype actually has 80% of the function available, so the team works from that base to complete the production version. In the process of creating the prototype, the team gave little thought to design and extensibility, and they had no time when creating the production version to produce a product that could be easily extended.

=== Cut-and-Paste Programming ===

==== Anti-Pattern Problem ====
An implementation contains "cloned" code throughout the project. A developer needs to solve a particular problem in his code which has already been implemented in a different section of code. He finds he can quickly gain the new function by just copying the original code to the new location. Problems occur when unknown bugs in the original code are replicated to the new code. Further, it is more difficult to enhance the code because one must know multiple places to make changes.

==== Refactored Solution ====
Cloned code can be refactored either through use of a common method or through inheritance. Additionally, going forward, a development team can attempt to identify likely code which should be usable, and they can design the code to exist in a reusable method or class.

==== Example ====
A developer is attempting to solve an issue in his section of the code which he knows has been solved in another area. He finds that he can quickly copy the foreign code into his code and resolve his issue. He knows that he could create a common method or class that he and the other code section could use, but he chooses not to do that because of the coordination with other developers that would be involved.

== Conclusion ==

Reviewing anti-patterns can be very beneficial to help you avoid the common pitfalls that inexperienced (and sometimes experienced) software developers fall in when writing software. Besides identifying design issues, anti-patterns can also give insight into the group dysfunction and business realities that also influence the production of software. Just as design patterns offer a shortcut for architects and developers in talking about implementation, anti-patterns can also offer a shortcut for describing issues to developers and others. Knowing about anti-patterns can also offer some comfort when the inevitable mistakes are made.

== References ==

* [http://www.antipatterns.com/ www.antipatterns.com]
* W. J. Brown et al., [http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis], John Wiley & Sons, Inc., New York, NY, 1998.
* S. Klement, [http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side], 2008
* Wikipedia entry: [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://c2.com/cgi/wiki?AntiPatternsCatalog Anti Patterns Catalog] offered by Cunningham & Cunningham, Inc.
* [http://sourcemaking.com/antipatterns What is an AntiPattern?] from Sourcemaking.com
* [http://www.lostechies.com/blogs/chrismissal/archive/2009/05/25/anti-patterns-and-worst-practices-you-re-doing-it-wrong.aspx Anti-Patterns and Worst Practices – You’re Doing it Wrong!]
* M. H. Dodani,[http://www.jot.fm/issues/issue_2006_07/column4.pdf Patterns of Anti-Patterns?], Journal of Object Technology, Vol 5, No 6, pp 29-33, 2006
* E. Gamma et al,[http://www.amazon.com/dp/0201633612 Design Patterns: Elements of Reusable Object-Oriented Software], Addison-Wesley Professional, 1994.
* G. Meszaros and J. Doble, [http://hillside.net/patterns/writing/patternwritingpaper.htm A Pattern Language for Pattern Writing].

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-18T02:14:12Z

Catowner: /* Cut-and-Paste Programming */

== Software Design Anti-Patterns ==

''Not all patterns are good. Anti-patterns are patterns that initially seem effective, but over time you learn that they lead you into traps.''
- Scott Klement, ''[http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side]''

In this article, we will describe several software design patterns which have been categorized as "anti patterns": Programming approaches which are not uncommon and which can lead to poor program design and performance.

== What are Anti-Patterns? ==

Different texts define the term '''anti-patterns''' in different ways:
* ''"An AntiPatern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences."'' - '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis]'''
* ''"Anti-patterns are patterns that initially seem effective, but over time you learn that they lead you into traps."'' - [http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side]
* Over the last decade we have witnessed the maturity of both best practices...and worst practices (as manifested in the anti-patterns movement...). - [http://www.jot.fm/issues/issue_2006_07/column4.pdf Patterns of Anti-Patterns?], Journal of Object Technology

In each definition, the implementer of the anti-pattern is trying to solve a problem in a common way, however the common way is a bad design that can lead to unintended consequences. Some of the reasons cited in the '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns]''' book as to why these anti-patterns have been used include: Haste, sloth (or laziness), ignorance, apathy, and pride. Studying anti-patterns can at least help assist the potential anti-pattern implementer in the ignorance category.

== Considerations When Writing Anti-Patterns ==

When writing patterns, there are various templates to from which to choose, for example, the pattern template from the Gang of Four's Design Pattern book:

* Pattern Name and Classification
* Intent
* Also Known As
* Motivation
* Applicability
* Structure
* Participants
* Collaboration
* Consequences
* Implementation
* Sample Code
* Known Uses
* Related Patterns

Brown et al in their book [http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns] suggest 3 different possible templates for writing anti-patterns:
* Pseudo-AntiPattern Template: Only the name and problem are described
* Mini-AntiPattern Template: Includes the name, AntiPattern Problems, and Refactored Solution
* Full AntiPattern Template: Includes 18 different sections such as Root Causes, Background, Known Exceptions, and Examples.

For the purposes of brevity, this wiki page will use the Mini-AntiPattern Template form with the addition of an Example section.

== Anti-Pattern Examples ==

This section presents six anti-patterns from the book '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis]'''.

=== The Blob ''or'' God Class ===

==== Anti-Pattern Problem ====
A design includes a class that has the majority of attributes and/or methods in the system. According to Brown et al, this anti-pattern could be the result of using a procedural design in an object-oriented language, and therefore imbuing one of the classes with the majority of the methods and seeing that class as a "controller" class. Another sign that the Blob anti-pattern may be present is if a class is designated as a "utility" class, which indicates a possible catch-all class for unrelated classes.

==== Refactored Solution ====
Brown et al suggests refactoring responsibilities into appropriate classes using the following steps:
* Identify cohesive sets of operations and attributes that relate to a common focus, behavior, or function.
* Review the system to see if there are "natural homes" for these collections in existing classes.
* Remove redundant or "far-coupled" associations.
* Migrate associates to derived classes to a common base class.
* Remove all transient associations, replacing them as appropriate with type specifiers to attributes and operations arguments.

==== Example ====
An inappropriate use of the Rails framework, where a majority of the methods reside in a single controller class or model class. To resolve the issues, helper classes or other classes could be created which would more appropriately contain related methods that were inappropriately kept in a controller or model.

=== Lava Flow ===

==== Anti-Pattern Problem ====
A design includes obsolete technologies or unused or misunderstood extensions. This problem usually occurs when prototype or research code is used as the basis for a production system, or when a code base has existed over a long period of time and the code base was not updated to reflect changes in surrounding technologies or systems.

==== Refactored Solution ====
Often times, the presence of obsolete or unused code is the result of lacking a sound design and architecture that is followed and updated throughout the system lifecycle. To resolve the issue of obsolete code, a redefinition of the architecture is necessary, with removal of "dead" code as the system is refactored to the new architecture. There is no easy fix for this issue, and it will take time to reengineer the system to remove redundancy and obsolescence.

==== Example ====
A financial program that helps customers manage their stock portfolio was developed as a web application with using HTML 2.0 and Java 1.3 servlets. Over time, the program was enhanced by building on the existing code base. Eventually the system was upgraded to serving XHTML 5 pages and using Java 6 in the server. Because of the lack of comprehensive design and architectural documentation, portions of the code use depracated methods and badly formatted HTML in places because the current development team does not understand the system to know what is "safe" to change or remove.

=== Poltergeists or Gypsy ===

==== Anti-Pattern Problem ====
A design which includes classes that have minimal responsibilities and roles in the system. These "poltergeists" appear only briefly in the system, possibly to invoke methods of other classes. Brown et al indicates these classes are usually a sign of an inexperience OO developer who has overdesigned the system.

==== Refactored Solution ====
Simply removed the "poltergeists" from the system altogether and then move the functionality to a related class.

==== Example ====
TBD

=== Golden Hammer ===

==== Anti-Pattern Problem ====
A system overuses a solution or vendor product to the detriment of the design and system itself. This can occur if a developer or development team has gotten comfortable with an approach or technology, and keeps going back to that approach or technology as the answer to all problems. Additionally, a development team may find itself forced into that situation for business reasons if their company has invested heavily in a product or technology and is expecting a return on that investment.

==== Refactored Solution ====
The refactoring for this anti-pattern involves a change in mindset as well as a software changes. The development team must acknowledge the appropriate use and limitations of the "favored" technology. Other approaches should be investigated and weighed fairly against each other. Where investments are involved, management may be needed to step in to make sure that technology investments are more evenly distributed.

==== Example ====
A developer new to Ruby on Rails needs to create a new data structure. Having created several models which also create new database tables, the developer defaults to creating another model which adds a new table to the database. This approach is not recommended for transient data when instead a simple class with attributes would suffice.

=== Spaghetti Code ===

==== Anti-Pattern Problem ====
A system appears to have little software structure. This type of anti-pattern can result when developers code first, and then possibly attempt to design along the way. The code with this issue is often difficult to understand, maintain, or enhance. The system is very closed and does not lend itself to reuse.

==== Refactored Solution ====
The solution in this case is to perform a major refactoring or clean-up on the system. Initially the goal should be to achieve an overall structure that is sensible, and then move toward improving performance and internal structures.

==== Example ====
A development team quickly creates a working prototype of a grade book, and are then pushed to provide a production version within 2 months. The working prototype actually has 80% of the function available, so the team works from that base to complete the production version. In the process of creating the prototype, the team gave little thought to design and extensibility, and they had no time when creating the production version to produce a product that could be easily extended.

=== Cut-and-Paste Programming ===

==== Anti-Pattern Problem ====
An implementation contains "cloned" code throughout the project. A developer needs to solve a particular problem in his code which has already been implemented in a different section of code. He finds he can quickly gain the new function by just copying the original code to the new location. Problems occur when unknown bugs in the original code are replicated to the new code. Further, it is more difficult to enhance the code because one must know multiple places to make changes.

==== Refactored Solution ====
Cloned code can be refactored either through use of a common method or through inheritance. Additionally, going forward, a development team can attempt to identify likely code which should be usable, and they can design the code to exist in a reusable method or class.

==== Example ====
A developer is attempting to solve an issue in his section of the code which he knows has been solved in another area. He finds that he can quickly copy the foreign code into his code and resolve his issue. He knows that he could create a common method or class that he and the other code section could use, but he chooses not to do that because of the coordination with other developers that would be involved.

== Conclusion ==

text

== References ==

* [http://www.antipatterns.com/ www.antipatterns.com]
* W. J. Brown et al., [http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis], John Wiley & Sons, Inc., New York, NY, 1998.
* S. Klement, [http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side], 2008
* Wikipedia entry: [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://c2.com/cgi/wiki?AntiPatternsCatalog Anti Patterns Catalog] offered by Cunningham & Cunningham, Inc.
* [http://sourcemaking.com/antipatterns What is an AntiPattern?] from Sourcemaking.com
* [http://www.lostechies.com/blogs/chrismissal/archive/2009/05/25/anti-patterns-and-worst-practices-you-re-doing-it-wrong.aspx Anti-Patterns and Worst Practices – You’re Doing it Wrong!]
* M. H. Dodani,[http://www.jot.fm/issues/issue_2006_07/column4.pdf Patterns of Anti-Patterns?], Journal of Object Technology, Vol 5, No 6, pp 29-33, 2006
* E. Gamma et al,[http://www.amazon.com/dp/0201633612 Design Patterns: Elements of Reusable Object-Oriented Software], Addison-Wesley Professional, 1994.
* G. Meszaros and J. Doble, [http://hillside.net/patterns/writing/patternwritingpaper.htm A Pattern Language for Pattern Writing].

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-18T02:04:38Z

Catowner: /* Spaghetti Code */

== Software Design Anti-Patterns ==

''Not all patterns are good. Anti-patterns are patterns that initially seem effective, but over time you learn that they lead you into traps.''
- Scott Klement, ''[http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side]''

In this article, we will describe several software design patterns which have been categorized as "anti patterns": Programming approaches which are not uncommon and which can lead to poor program design and performance.

== What are Anti-Patterns? ==

Different texts define the term '''anti-patterns''' in different ways:
* ''"An AntiPatern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences."'' - '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis]'''
* ''"Anti-patterns are patterns that initially seem effective, but over time you learn that they lead you into traps."'' - [http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side]
* Over the last decade we have witnessed the maturity of both best practices...and worst practices (as manifested in the anti-patterns movement...). - [http://www.jot.fm/issues/issue_2006_07/column4.pdf Patterns of Anti-Patterns?], Journal of Object Technology

In each definition, the implementer of the anti-pattern is trying to solve a problem in a common way, however the common way is a bad design that can lead to unintended consequences. Some of the reasons cited in the '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns]''' book as to why these anti-patterns have been used include: Haste, sloth (or laziness), ignorance, apathy, and pride. Studying anti-patterns can at least help assist the potential anti-pattern implementer in the ignorance category.

== Considerations When Writing Anti-Patterns ==

When writing patterns, there are various templates to from which to choose, for example, the pattern template from the Gang of Four's Design Pattern book:

* Pattern Name and Classification
* Intent
* Also Known As
* Motivation
* Applicability
* Structure
* Participants
* Collaboration
* Consequences
* Implementation
* Sample Code
* Known Uses
* Related Patterns

Brown et al in their book [http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns] suggest 3 different possible templates for writing anti-patterns:
* Pseudo-AntiPattern Template: Only the name and problem are described
* Mini-AntiPattern Template: Includes the name, AntiPattern Problems, and Refactored Solution
* Full AntiPattern Template: Includes 18 different sections such as Root Causes, Background, Known Exceptions, and Examples.

For the purposes of brevity, this wiki page will use the Mini-AntiPattern Template form with the addition of an Example section.

== Anti-Pattern Examples ==

This section presents six anti-patterns from the book '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis]'''.

=== The Blob ''or'' God Class ===

==== Anti-Pattern Problem ====
A design includes a class that has the majority of attributes and/or methods in the system. According to Brown et al, this anti-pattern could be the result of using a procedural design in an object-oriented language, and therefore imbuing one of the classes with the majority of the methods and seeing that class as a "controller" class. Another sign that the Blob anti-pattern may be present is if a class is designated as a "utility" class, which indicates a possible catch-all class for unrelated classes.

==== Refactored Solution ====
Brown et al suggests refactoring responsibilities into appropriate classes using the following steps:
* Identify cohesive sets of operations and attributes that relate to a common focus, behavior, or function.
* Review the system to see if there are "natural homes" for these collections in existing classes.
* Remove redundant or "far-coupled" associations.
* Migrate associates to derived classes to a common base class.
* Remove all transient associations, replacing them as appropriate with type specifiers to attributes and operations arguments.

==== Example ====
An inappropriate use of the Rails framework, where a majority of the methods reside in a single controller class or model class. To resolve the issues, helper classes or other classes could be created which would more appropriately contain related methods that were inappropriately kept in a controller or model.

=== Lava Flow ===

==== Anti-Pattern Problem ====
A design includes obsolete technologies or unused or misunderstood extensions. This problem usually occurs when prototype or research code is used as the basis for a production system, or when a code base has existed over a long period of time and the code base was not updated to reflect changes in surrounding technologies or systems.

==== Refactored Solution ====
Often times, the presence of obsolete or unused code is the result of lacking a sound design and architecture that is followed and updated throughout the system lifecycle. To resolve the issue of obsolete code, a redefinition of the architecture is necessary, with removal of "dead" code as the system is refactored to the new architecture. There is no easy fix for this issue, and it will take time to reengineer the system to remove redundancy and obsolescence.

==== Example ====
A financial program that helps customers manage their stock portfolio was developed as a web application with using HTML 2.0 and Java 1.3 servlets. Over time, the program was enhanced by building on the existing code base. Eventually the system was upgraded to serving XHTML 5 pages and using Java 6 in the server. Because of the lack of comprehensive design and architectural documentation, portions of the code use depracated methods and badly formatted HTML in places because the current development team does not understand the system to know what is "safe" to change or remove.

=== Poltergeists or Gypsy ===

==== Anti-Pattern Problem ====
A design which includes classes that have minimal responsibilities and roles in the system. These "poltergeists" appear only briefly in the system, possibly to invoke methods of other classes. Brown et al indicates these classes are usually a sign of an inexperience OO developer who has overdesigned the system.

==== Refactored Solution ====
Simply removed the "poltergeists" from the system altogether and then move the functionality to a related class.

==== Example ====
TBD

=== Golden Hammer ===

==== Anti-Pattern Problem ====
A system overuses a solution or vendor product to the detriment of the design and system itself. This can occur if a developer or development team has gotten comfortable with an approach or technology, and keeps going back to that approach or technology as the answer to all problems. Additionally, a development team may find itself forced into that situation for business reasons if their company has invested heavily in a product or technology and is expecting a return on that investment.

==== Refactored Solution ====
The refactoring for this anti-pattern involves a change in mindset as well as a software changes. The development team must acknowledge the appropriate use and limitations of the "favored" technology. Other approaches should be investigated and weighed fairly against each other. Where investments are involved, management may be needed to step in to make sure that technology investments are more evenly distributed.

==== Example ====
A developer new to Ruby on Rails needs to create a new data structure. Having created several models which also create new database tables, the developer defaults to creating another model which adds a new table to the database. This approach is not recommended for transient data when instead a simple class with attributes would suffice.

=== Spaghetti Code ===

==== Anti-Pattern Problem ====
A system appears to have little software structure. This type of anti-pattern can result when developers code first, and then possibly attempt to design along the way. The code with this issue is often difficult to understand, maintain, or enhance. The system is very closed and does not lend itself to reuse.

==== Refactored Solution ====
The solution in this case is to perform a major refactoring or clean-up on the system. Initially the goal should be to achieve an overall structure that is sensible, and then move toward improving performance and internal structures.

==== Example ====
A development team quickly creates a working prototype of a grade book, and are then pushed to provide a production version within 2 months. The working prototype actually has 80% of the function available, so the team works from that base to complete the production version. In the process of creating the prototype, the team gave little thought to design and extensibility, and they had no time when creating the production version to produce a product that could be easily extended.

=== Cut-and-Paste Programming ===

==== Anti-Pattern Problem ====
text

==== Refactored Solution ====
text

==== Example ====
text

== Conclusion ==

text

== References ==

* [http://www.antipatterns.com/ www.antipatterns.com]
* W. J. Brown et al., [http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis], John Wiley & Sons, Inc., New York, NY, 1998.
* S. Klement, [http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side], 2008
* Wikipedia entry: [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://c2.com/cgi/wiki?AntiPatternsCatalog Anti Patterns Catalog] offered by Cunningham & Cunningham, Inc.
* [http://sourcemaking.com/antipatterns What is an AntiPattern?] from Sourcemaking.com
* [http://www.lostechies.com/blogs/chrismissal/archive/2009/05/25/anti-patterns-and-worst-practices-you-re-doing-it-wrong.aspx Anti-Patterns and Worst Practices – You’re Doing it Wrong!]
* M. H. Dodani,[http://www.jot.fm/issues/issue_2006_07/column4.pdf Patterns of Anti-Patterns?], Journal of Object Technology, Vol 5, No 6, pp 29-33, 2006
* E. Gamma et al,[http://www.amazon.com/dp/0201633612 Design Patterns: Elements of Reusable Object-Oriented Software], Addison-Wesley Professional, 1994.
* G. Meszaros and J. Doble, [http://hillside.net/patterns/writing/patternwritingpaper.htm A Pattern Language for Pattern Writing].

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-18T01:53:39Z

Catowner: /* Golden Hammer */

== Software Design Anti-Patterns ==

''Not all patterns are good. Anti-patterns are patterns that initially seem effective, but over time you learn that they lead you into traps.''
- Scott Klement, ''[http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side]''

In this article, we will describe several software design patterns which have been categorized as "anti patterns": Programming approaches which are not uncommon and which can lead to poor program design and performance.

== What are Anti-Patterns? ==

Different texts define the term '''anti-patterns''' in different ways:
* ''"An AntiPatern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences."'' - '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis]'''
* ''"Anti-patterns are patterns that initially seem effective, but over time you learn that they lead you into traps."'' - [http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side]
* Over the last decade we have witnessed the maturity of both best practices...and worst practices (as manifested in the anti-patterns movement...). - [http://www.jot.fm/issues/issue_2006_07/column4.pdf Patterns of Anti-Patterns?], Journal of Object Technology

In each definition, the implementer of the anti-pattern is trying to solve a problem in a common way, however the common way is a bad design that can lead to unintended consequences. Some of the reasons cited in the '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns]''' book as to why these anti-patterns have been used include: Haste, sloth (or laziness), ignorance, apathy, and pride. Studying anti-patterns can at least help assist the potential anti-pattern implementer in the ignorance category.

== Considerations When Writing Anti-Patterns ==

When writing patterns, there are various templates to from which to choose, for example, the pattern template from the Gang of Four's Design Pattern book:

* Pattern Name and Classification
* Intent
* Also Known As
* Motivation
* Applicability
* Structure
* Participants
* Collaboration
* Consequences
* Implementation
* Sample Code
* Known Uses
* Related Patterns

Brown et al in their book [http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns] suggest 3 different possible templates for writing anti-patterns:
* Pseudo-AntiPattern Template: Only the name and problem are described
* Mini-AntiPattern Template: Includes the name, AntiPattern Problems, and Refactored Solution
* Full AntiPattern Template: Includes 18 different sections such as Root Causes, Background, Known Exceptions, and Examples.

For the purposes of brevity, this wiki page will use the Mini-AntiPattern Template form with the addition of an Example section.

== Anti-Pattern Examples ==

This section presents six anti-patterns from the book '''[http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis]'''.

=== The Blob ''or'' God Class ===

==== Anti-Pattern Problem ====
A design includes a class that has the majority of attributes and/or methods in the system. According to Brown et al, this anti-pattern could be the result of using a procedural design in an object-oriented language, and therefore imbuing one of the classes with the majority of the methods and seeing that class as a "controller" class. Another sign that the Blob anti-pattern may be present is if a class is designated as a "utility" class, which indicates a possible catch-all class for unrelated classes.

==== Refactored Solution ====
Brown et al suggests refactoring responsibilities into appropriate classes using the following steps:
* Identify cohesive sets of operations and attributes that relate to a common focus, behavior, or function.
* Review the system to see if there are "natural homes" for these collections in existing classes.
* Remove redundant or "far-coupled" associations.
* Migrate associates to derived classes to a common base class.
* Remove all transient associations, replacing them as appropriate with type specifiers to attributes and operations arguments.

==== Example ====
An inappropriate use of the Rails framework, where a majority of the methods reside in a single controller class or model class. To resolve the issues, helper classes or other classes could be created which would more appropriately contain related methods that were inappropriately kept in a controller or model.

=== Lava Flow ===

==== Anti-Pattern Problem ====
A design includes obsolete technologies or unused or misunderstood extensions. This problem usually occurs when prototype or research code is used as the basis for a production system, or when a code base has existed over a long period of time and the code base was not updated to reflect changes in surrounding technologies or systems.

==== Refactored Solution ====
Often times, the presence of obsolete or unused code is the result of lacking a sound design and architecture that is followed and updated throughout the system lifecycle. To resolve the issue of obsolete code, a redefinition of the architecture is necessary, with removal of "dead" code as the system is refactored to the new architecture. There is no easy fix for this issue, and it will take time to reengineer the system to remove redundancy and obsolescence.

==== Example ====
A financial program that helps customers manage their stock portfolio was developed as a web application with using HTML 2.0 and Java 1.3 servlets. Over time, the program was enhanced by building on the existing code base. Eventually the system was upgraded to serving XHTML 5 pages and using Java 6 in the server. Because of the lack of comprehensive design and architectural documentation, portions of the code use depracated methods and badly formatted HTML in places because the current development team does not understand the system to know what is "safe" to change or remove.

=== Poltergeists or Gypsy ===

==== Anti-Pattern Problem ====
A design which includes classes that have minimal responsibilities and roles in the system. These "poltergeists" appear only briefly in the system, possibly to invoke methods of other classes. Brown et al indicates these classes are usually a sign of an inexperience OO developer who has overdesigned the system.

==== Refactored Solution ====
Simply removed the "poltergeists" from the system altogether and then move the functionality to a related class.

==== Example ====
TBD

=== Golden Hammer ===

==== Anti-Pattern Problem ====
A system overuses a solution or vendor product to the detriment of the design and system itself. This can occur if a developer or development team has gotten comfortable with an approach or technology, and keeps going back to that approach or technology as the answer to all problems. Additionally, a development team may find itself forced into that situation for business reasons if their company has invested heavily in a product or technology and is expecting a return on that investment.

==== Refactored Solution ====
The refactoring for this anti-pattern involves a change in mindset as well as a software changes. The development team must acknowledge the appropriate use and limitations of the "favored" technology. Other approaches should be investigated and weighed fairly against each other. Where investments are involved, management may be needed to step in to make sure that technology investments are more evenly distributed.

==== Example ====
A developer new to Ruby on Rails needs to create a new data structure. Having created several models which also create new database tables, the developer defaults to creating another model which adds a new table to the database. This approach is not recommended for transient data when instead a simple class with attributes would suffice.

=== Spaghetti Code ===

==== Anti-Pattern Problem ====
text

==== Refactored Solution ====
text

==== Example ====
text

=== Cut-and-Paste Programming ===

==== Anti-Pattern Problem ====
text

==== Refactored Solution ====
text

==== Example ====
text

== Conclusion ==

text

== References ==

* [http://www.antipatterns.com/ www.antipatterns.com]
* W. J. Brown et al., [http://www.amazon.com/exec/obidos/ASIN/0471197130/theantipatterngr AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis], John Wiley & Sons, Inc., New York, NY, 1998.
* S. Klement, [http://systeminetwork.com/article/anti-patterns-avoid-programming-dark-side Anti-Patterns: Avoid the Programming Dark Side], 2008
* Wikipedia entry: [http://en.wikipedia.org/wiki/Anti-pattern Anti-pattern]
* [http://c2.com/cgi/wiki?AntiPatternsCatalog Anti Patterns Catalog] offered by Cunningham & Cunningham, Inc.
* [http://sourcemaking.com/antipatterns What is an AntiPattern?] from Sourcemaking.com
* [http://www.lostechies.com/blogs/chrismissal/archive/2009/05/25/anti-patterns-and-worst-practices-you-re-doing-it-wrong.aspx Anti-Patterns and Worst Practices – You’re Doing it Wrong!]
* M. H. Dodani,[http://www.jot.fm/issues/issue_2006_07/column4.pdf Patterns of Anti-Patterns?], Journal of Object Technology, Vol 5, No 6, pp 29-33, 2006
* E. Gamma et al,[http://www.amazon.com/dp/0201633612 Design Patterns: Elements of Reusable Object-Oriented Software], Addison-Wesley Professional, 1994.
* G. Meszaros and J. Doble, [http://hillside.net/patterns/writing/patternwritingpaper.htm A Pattern Language for Pattern Writing].

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-18T01:42:13Z

Catowner: /* Poltergeists */

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-18T01:28:37Z

Catowner: /* Lava Flow */

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-18T01:13:49Z

Catowner: /* Lava Flow */

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-18T01:06:02Z

Catowner: /* The Blob ''or'' God Class */

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-18T01:04:17Z

Catowner: /* Anti-Pattern Examples */

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-18T00:53:10Z

Catowner: /* Anti-Pattern Examples */

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-17T22:39:16Z

Catowner: /* Considerations When Writing Anti-Patterns */

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-17T22:28:36Z

Catowner: /* References */

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-17T22:18:58Z

Catowner: /* References */

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-17T22:14:28Z

Catowner: /* What are Anti-Patterns? */

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-17T04:01:36Z

Catowner: /* References */

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-17T03:57:03Z

Catowner: /* References */

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-17T03:56:38Z

Catowner: /* References */

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-15T22:06:46Z

Catowner:

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-15T17:43:49Z

Catowner:

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-15T17:38:05Z

Catowner:

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-15T15:43:20Z

Catowner:

CSC/ECE 517 Fall 2009/wiki3 1 co

2009-11-08T23:41:42Z

Catowner:

== Software Design Anti-Patterns ==

''From Wikipedia: "In software engineering, an anti-pattern (or antipattern) is a design pattern that may be commonly used but is ineffective and/or counterproductive in practice." Identify several software design anti-patterns and how they can be avoided, countered, or refactored. This wiki should focus on software design anti-patterns and avoid the larger definition which includes project management or other socially-themed anti-patterns.''

CSC/ECE 517 Fall 2009/wiki2 7 co

2009-10-15T00:20:39Z

Catowner:

== Code Reuse Methods and Mechanisms ==

''The best way to attack the essence of building software is not to build it at all.''
- [http://en.wikipedia.org/wiki/Fred_Brooks Fredrick P. Brooks, Jr.],''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month The Mythical Man-Month]''

In his 1975 classic, ''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month The Mythical Man-Month]'', [http://en.wikipedia.org/wiki/Fred_Brooks Fred Brooks] claimed that the implementation of design (what he called "accidental tasks") was essentially efficient enough that improvements in that area would not result in significant gains in productivity. Twenty years later, in a follow-up edition, he refined and clarified his view. He recognized that the rise of object-oriented languages and methodologies had the potential and promise of easy reuse, although he was still skeptical of dramatic productivity claims. Fundamentally, though, he saw that overall software development productivity can be enhanced through reuse.

This page will review some of the different techniques that are available for code reuse, and then a comparison of the techniques will be presented.

== Code Reuse Through Direct Code Use ==

There are several classic code reuse mechanisms which work at the fundamental source code level. This section will discuss this class of mechanisms.

=== Cut & Paste ===

One of the most basic reuse mechanism is the cut and paste method. Simply find the source code that performs the function that is required and copy the code into the place it is needed. This method can be implemented either by copying from some external source, such as a book or another software program, or by duplicating the same code within the same program. The latter method is generally a [http://sourcemaking.com/antipatterns/cut-and-paste-programming very discouraged practice]. Additionally, using this method can lead to [http://en.wikipedia.org/wiki/Copy_and_paste_programming plagiarism].

=== Includes ===

In C and C++, the '''includes''' construct places the contents of the file specified in the include parameter in the spot where the include is placed:

#include "time.h"

class Time
{...

In this example, the compiler effectively copies the code within time.h at the point where the #include statement is declared. Nearly all compilers will provide for specifying paths to search for the indicated file and provide rules or conventions for dealing with multiple occurrences of the same file.

== Code Reuse through Subroutines ==

This section explores code reuse mechanisms that involve executing common blocks of code that can provide utility or common operations.

=== Gosub ===

In [http://www.vintage-basic.net/ Vintage Basic] (comparable to the Basic language dialects from the late 70s and early 80s), individual lines of code are designated by line numbers. Blocks of code can be designated as subroutines and the '''GOSUB''' command can jump to these blocks of code. Execution jumps back to the line following the GOSUB command once a '''RETURN''' is encountered in the subroutine:

10 FOR I=1 TO 5
20 GOSUB 100
30 NEXT I
40 END
100 PRINT "Value = "; I
110 RETURN

Note that in this construct, parameters are not passed to the subroutine, but since all variables were global, parameters could still be simulated through careful use of global variables.

=== Procedures ===

In Pascal, [http://www.taoyue.com/tutorials/pascal/pas4a.html '''procedures'''] provided a way to jump to a block of code, and parameters can be passed to that block as well:

var j:Integer;

procedure PrintValue(i: Integer);
begin
Write("Value = ");
Writeln(i);
end;

begin
for j := 1 to 5 do
PrintValue(j)
end.

In this scheme, in order to update parameters with actions performed within the procedure, a parameter must be [http://www.arl.wustl.edu/~lockwood/class/cs306/books/artofasm/Chapter_11/CH11-2.html#HEADING2-29 '''passed by reference'''], effectively passing the memory address of the parameter so it can be effected directly.

=== Functions ===

Pascal also includes a construct called [http://www.taoyue.com/tutorials/pascal/pas4c.html '''functions'''] which allow a subroutine to return a value to the caller:

var j:Integer;

function Square(i: Integer): Integer;
begin
Square = i * i;
end;

begin
for j := 1 to 5 do
Writeln("Square of ", j, " = ", Square(j));
end.

Although a similar construct can be created using procedures, functions allow for more concise coding.

== Code Reuse through Extension ==

Many languages allow existing code to be reused through extensions that leave the original code unaltered. This section explores those mechanisms.

=== Methods ===

'''Methods''' (in [http://java.sun.com/docs/books/tutorial/java/javaOO/methods.html Java] and [http://www.cplusplus.com/doc/tutorial/classes/ C++]) are functions which are encapsulated within a class structure. The class structure can provide a level of data and implementation hiding which can facilitate better design.

public class Square {
int size;
...
public void draw() {
...
}
}

In and of themselves, methods do not offer any additional capability over functions, but operating within a class structure, several object-oriented paradigms can make methods more effective for code reuse.

=== Inheritance ===

'''Inheritance''' is an object-oriented concept which allows a developer to create subclasses of a base class which can refine or expand the base class.

public class Rectangle {
int width, height;
public Rectangle(int w, int h) {
...
}
...
}

public class Square extends Rectangle {
int size;
public Square(int s) {
super(s,s);
...
}
...
}

In this example, the Square class extend the Rectangle class. In the Square constructor, the Rectangle constructor is called and, thus, is reused.

Using inheritance, base classes can hold much of the common elements that are used by the subclasses. Code is reused by the subclasses through the common base class.

=== Polymorphism ===

'''Polymorphism''' is another object-oriented concept which allows a developer to reuse a defined interface in a class, but provide for an implementation that is specialized to that specific class.

abstract public class Shape {
abstract public void draw();
}

public class Square extends Shape {
public draw() {
...
}
}

public class Circle extends Shape {
public draw() {
...
}
}

In this example, the draw method has been indicated in the Shape class, but implemented in the subclasses Square and Circle. This example may not seem like code reuse, but it can be argued that the concept around providing a common signature for the subclasses is a type of reuse. Further, polymorphism provides one of the key foundations for object-oriented programming.

=== Generics ===

'''Generics''' in Java and C++ provide a mechanism where a type or class (such as String, int, or Shape) can be provided to a method as a parameter. In this fashion, the generic method can accommodate multiple types, or they can be used to catch potential typing issues at compile time that might otherwise be missed.

* [http://java.sun.com/docs/books/tutorial/extra/generics/index.html Tutorial on Generics in Java]
* [http://msdn.microsoft.com/en-us/library/c570k3f3%28VS.80%29.aspx Overview of Generics in Visual C++]

One example of generics in Java is in the java.util class for [http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html collection classes]. In the declaration for the Collection class, the type is declared in angle brackets ("<Type>") and is implicitly provided as a parameter to the class and instance methods for an object of that class. So, instead of having to write one Collection class for Integers, another for Strings, another for Shapes, etc., using generics allows a single class to support multiple types, which enables the class to be utilized to a much greater extent.

=== Mixins/Modules ===

In Ruby, classes and modules can be combined to provide a [http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ "mixin"]. Modules are code blocks which define methods which are not directly associate with a particular class:

module Greeter
def sayHi(name)
puts "Hi $#{@name}"
end

module Shouter
def yellHello(name)
puts "HELLO $#{@name}"
end

As you can see, sayHi and YellHello are methods with implementations, but they are not associated with a specific class. These modules can be associated with a class in one of two ways. Through the class definition:

class Talker
include Greeter
extend Shouter
...
end

class TalkerToo
...
end

...or an instance of the class can be mixed at runtime:

ttoo = TalkerToo.new
ttoo.extend Shouter
ttoo.include Greeter

Extending a class or instance with a module adds the methods as class methods. Including a class or instance with a module adds the methods as instance methods.

The Ruby language provides some specific modules that can be used to extend classes such as [http://www.ruby-doc.org/core/classes/Comparable.html Comparable] and [http://www.ruby-doc.org/core/classes/Enumerable.html Enumerable].

=== Aspect ===

[http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-oriented programming] is a methodology which supports the separation of concerns for a program feature which would normally have to intrude into several different modules which are not related to that feature. A common example of a cross-cutting concern is logging program execution, where every method entry and exit may warrant a message added to a log file. By using an aspect, the logging function can be defined outside of the implementation of the rest of the program, leaving the rest of the implementation decoupled from the logging implementation.

Aspect mechanisms are available for both Ruby and Java:
* For Ruby there is [http://aspectr.sourceforge.net/ AspectR] and [http://aquarium.rubyforge.org/ Aquarium]. Both are provided as modules which are included within the target implementation.
* For Java, one of the leading mechanisms is [http://www.eclipse.org/aspectj/ AspectJ] which is an Eclipse-homed implementation. Additional tooling, called [http://www.eclipse.org/ajdt/ AJDT], is provided as well.
* Several [http://java-source.net/open-source/aspect-oriented-frameworks AOP Frameworks for Java] are available.

Although touted as a method for separation of concerns, aspects also provide a way for programmers to provide a set of code which interacts broadly across a system, and thus reuse of the either the aspect or the functions within a system is achieved, similarly to how function or method calls achieve code reuse.

== Comparing the Various Mechanisms ==

{| style="background:silver; color:blue" border="1" cellpadding="2"
!width="100"|Reuse Mechanism
!width="200"|Simplicity/Complexity
!width="200"|Versatility
!width="200"|Performance/Efficiency
|- style="background:white; color:black"
|Cut & Paste || Extremely easy to implement || Not very versatile; requires careful attention in editing; changes in function require understanding of implementation || Highly inefficient; potential to have multiple copies of the same code throughout system
|- style="background:white; color:black"
| Include || Very easy to implement || Not versatile; potentially requires detail knowledge of the entity being included || Poor performance; the include is effectively cut and paste without the cognitive baggage
|- style="background:white; color:black"
| Gosub|| Very easy to implement || Can be versatile through use of global variables as switches, however subroutine loose cohesion || Somewhat more efficient than cut and paste and include in terms of memory and program size; variables are "passed" via global means
|- style="background:white; color:black"
| Procedures || Easy to implement || Fairly versatile though use of parameters || More efficient than gosub: Parameters provide local variables (on the stack) to the procedure, and potentially save global memory.
|- style="background:white; color:black"
| Functions || Easy to implement || Slightly more versatile with addition of return value in addition to parameters || Similar to procedures
|- style="background:white; color:black"
| Methods || Fairly easy to implement || Can be highly versatile, especially if well designed and associate class and method are self-documenting, providing ease-of-use || Although there may be several instances of an object being used, the methods associated with those objects generally occupy a single space in memory providing for efficient performance.
|- style="background:white; color:black"
| Inheritance || Takes some thought to do well || Somewhat versatile, but to be well-designed, the subclasses must relate well to the superclass || Should provide an additional layer of efficiency since some methods can be shared by multiple classes
|- style="background:white; color:black"
| Polymorphism || Somewhat difficult to implement well || If well designed, polymorphism adds a layer of versatility over just plain inheritance: The consumer has less concern about the specifics being implemented by the method being called || Polymorphism requires run-time identification of objects to determine what method should actually be executed, and this factor can reduce performance, however depending on the compiler, [http://www.javaspecialists.eu/archive/Issue158.html it cannot be assumed that polymorphism always affects performance negatively].
|- style="background:white; color:black"
| Generics || Moderately difficult to use and takes careful design to implement well || Can be highly versatile; When designed correctly, source code that is agnostic to object types can be reused by multiple objects || Sun's Java [http://java.sun.com/developer/technicalArticles/J2SE/generics/ implements generics] via parameter passing of the generic type whereas C++ uses a macro-based mechanism to replace the type in the original generic source. In this fashion, the Java version of generics produces a smaller footprint than C++.
|- style="background:white; color:black"
| Mixins/Modules || Not difficult to implement, but careful thought is needed to make highly reusable || Can be highly versatile, providing common methods to a few classes or instances, or providing a broader capability akin to aspects || From a coding perspective, can be highly effective; Mixins, as well as the nature of [http://www.joelonsoftware.com/items/2006/09/12.html |an interpretive late-binding language and duck typing] don't bode well for performance compared to other methods
|- style="background:white; color:black"
| Aspects || Can be difficult to implement well || Not very versatile, focused primarily on cross-system features || From a coding perspective, can be highly efficient; From a system execution perspective, performance is dependent on implementation of aspect-capability
|}

== Encouraging Reuse ==

With all the various techniques available, code reuse is not universally embraced, either academically or commercially. [http://www.itstrategycenter.com/wbbm/Res/analytics/black_art_of_reusing_software/index.html CIO Strategy Center] recommends 4 key actions to encourage code reuse in a company:

* Build a business case to get buy-in from the organization's business leaders.
* Establish repeatable, practical processes which reduce the potential roadblocks in developing reusable code.
* Focus on ways the design process can facilitate code reuse.
* Shift the business culture to a reuse mindset.

From an academic perspective, encouraging code reuse can be tricky, especially given concerns about maintaining academic integrity. One way education institutions are doing both is through encouraging students to participate in [http://arstechnica.com/open-source/news/2009/06/academic-source-code-dust-up-symptom-of-cs-education-ills.ars open source projects].

== Conclusion ==

Software reuse can take many forms, with those forms offering many levels of complexity and utility. With careful planning and thoughtful design, software reuse has the potential to speed development time and improve software reliability.

== References ==

* Brooks, Jr., F.P. ''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month The Mythical Man-Month]''. Boston, MA: Addison Wesley Longman, Inc., 1995.
* [http://sourcemaking.com/antipatterns/cut-and-paste-programming Cut-and-Paste Programming]
* [http://www.vintage-basic.net/ Vintage Basic]
* [http://www.taoyue.com/tutorials/pascal/ Pascal Tutorial]
* [http://java.sun.com/docs/books/tutorial/ Sun's Java Tutorials]
* [http://java.sun.com/docs/books/tutorial/extra/generics/index.html Tutorial on Generics in Java]
* [http://msdn.microsoft.com/en-us/library/c570k3f3%28VS.80%29.aspx Overview of Generics in Visual C++]
* [http://www.ruby-lang.org/en/ Official Ruby Language web site]
* [http://en.wikipedia.org/wiki/Why%27s_%28poignant%29_Guide_to_Ruby Info about Why's (poignant) Guide to Ruby] - a very quirky Ruby tutorial
* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Wikipedia Entry: Aspect-oriented programming]
** [http://aspectr.sourceforge.net/ AspectR]
** [http://aquarium.rubyforge.org/ Aquarium]
** [http://java-source.net/open-source/aspect-oriented-frameworks AOP Frameworks for Java]

CSC/ECE 517 Fall 2009/wiki2 7 co

2009-10-15T00:07:42Z

Catowner:

CSC/ECE 517 Fall 2009/wiki2 7 co

2009-10-15T00:03:40Z

Catowner: /* Conclusion */

== Code Reuse Methods and Mechanisms ==

''The best way to attack the essence of building software is not to build it at all.''
- [http://en.wikipedia.org/wiki/Fred_Brooks Fredrick P. Brooks, Jr.],''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month The Mythical Man-Month]''

In his 1975 classic, ''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month The Mythical Man-Month]'', [http://en.wikipedia.org/wiki/Fred_Brooks Fred Brooks] claimed that the implementation of design (what he called "accidental tasks") was essentially efficient enough that improvements in that area would not result in significant gains in productivity. Twenty years later, in a follow-up edition, he refined and clarified his view. He recognized that the rise of object-oriented languages and methodologies had the potential and promise of easy reuse, although he was still skeptical of dramatic productivity claims. Fundamentally, though, he saw that overall software development productivity can be enhanced through reuse.

This page will review some of the different techniques that are available for code reuse, and then a comparison of the techniques will be presented.

== Code Reuse Through Direct Code Use ==

There are several classic code reuse mechanisms which work at the fundamental source code level. This section will discuss this class of mechanisms.

=== Cut & Paste ===

One of the most basic reuse mechanism is the cut and paste method. Simply find the source code that performs the function that is required and copy the code into the place it is needed. This method can be implemented either by copying from some external source, such as a book or another software program, or by duplicating the same code within the same program. The latter method is generally a [http://sourcemaking.com/antipatterns/cut-and-paste-programming very discouraged practice]. Additionally, using this method can lead to [http://en.wikipedia.org/wiki/Copy_and_paste_programming plagiarism].

=== Includes ===

In C and C++, the '''includes''' construct places the contents of the file specified in the include parameter in the spot where the include is placed:

#include "time.h"

class Time
{...

In this example, the compiler effectively copies the code within time.h at the point where the #include statement is declared. Nearly all compilers will provide for specifying paths to search for the indicated file and provide rules or conventions for dealing with multiple occurrences of the same file.

== Code Reuse through Subroutines ==

This section explores code reuse mechanisms that involve executing common blocks of code that can provide utility or common operations.

=== Gosub ===

In [http://www.vintage-basic.net/ Vintage Basic] (comparable to the Basic language dialects from the late 70s and early 80s), individual lines of code are designated by line numbers. Blocks of code can be designated as subroutines and the '''GOSUB''' command can jump to these blocks of code. Execution jumps back to the line following the GOSUB command once a '''RETURN''' is encountered in the subroutine:

10 FOR I=1 TO 5
20 GOSUB 100
30 NEXT I
40 END
100 PRINT "Value = "; I
110 RETURN

Note that in this construct, parameters are not passed to the subroutine, but since all variables were global, parameters could still be simulated through careful use of global variables.

=== Procedures ===

In Pascal, '''procedures''' provided a way to jump to a block of code, and parameters can be passed to that block as well:

var j:Integer;

procedure PrintValue(i: Integer);
begin
Write("Value = ");
Writeln(i);
end;

begin
for j := 1 to 5 do
PrintValue(j)
end.

In this scheme, in order to update parameters with actions performed within the procedure, a parameter must be [http://www.arl.wustl.edu/~lockwood/class/cs306/books/artofasm/Chapter_11/CH11-2.html#HEADING2-29 '''passed by reference'''], effectively passing the memory address of the parameter so it can be effected directly.

=== Functions ===

Pascal also includes a construct called '''functions''' which allow a subroutine to return a value to the caller:

var j:Integer;

function Square(i: Integer): Integer;
begin
Square = i * i;
end;

begin
for j := 1 to 5 do
Writeln("Square of ", j, " = ", Square(j));
end.

Although a similar construct can be created using procedures, functions allow for more concise coding.

== Code Reuse through Extension ==

Many languages allow existing code to be reused through extensions that leave the original code unaltered. This section explores those mechanisms.

=== Methods ===

'''Methods''' (in [http://java.sun.com/docs/books/tutorial/java/javaOO/methods.html Java] and [http://www.cplusplus.com/doc/tutorial/classes/ C++]) are functions which are encapsulated within a class structure. The class structure can provide a level of data and implementation hiding which can facilitate better design.

public class Square {
int size;
...
public void draw() {
...
}
}

In and of themselves, methods do not offer any additional capability over functions, but operating within a class structure, several object-oriented paradigms can make methods more effective for code reuse.

=== Inheritance ===

'''Inheritance''' is an object-oriented concept which allows a developer to create subclasses of a base class which can refine or expand the base class.

public class Rectangle {
int width, height;
public Rectangle(int w, int h) {
...
}
...
}

public class Square extends Rectangle {
int size;
public Square(int s) {
super(s,s);
...
}
...
}

In this example, the Square class extend the Rectangle class. In the Square constructor, the Rectangle constructor is called and, thus, is reused.

Using inheritance, base classes can hold much of the common elements that are used by the subclasses. Code is reused by the subclasses through the common base class.

=== Polymorphism ===

'''Polymorphism''' is another object-oriented concept which allows a developer to reuse a defined interface in a class, but provide for an implementation that is specialized to that specific class.

abstract public class Shape {
abstract public void draw();
}

public class Square extends Shape {
public draw() {
...
}
}

public class Circle extends Shape {
public draw() {
...
}
}

In this example, the draw method has been indicated in the Shape class, but implemented in the subclasses Square and Circle. This example may not seem like code reuse, but it can be argued that the concept around providing a common signature for the subclasses is a type of reuse. Further, polymorphism provides one of the key foundations for object-oriented programming.

=== Generics ===

'''Generics''' in Java and C++ provide a mechanism where a type or class (such as String, int, or Shape) can be provided to a method as a parameter. In this fashion, the generic method can accommodate multiple types, or they can be used to catch potential typing issues at compile time that might otherwise be missed.

* [http://java.sun.com/docs/books/tutorial/extra/generics/index.html Tutorial on Generics in Java]
* [http://msdn.microsoft.com/en-us/library/c570k3f3%28VS.80%29.aspx Overview of Generics in Visual C++]

One example of generics in Java is in the java.util class for [http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html collection classes]. In the declaration for the Collection class, the type is declared in angle brackets ("<Type>") and is implicitly provided as a parameter to the class and instance methods for an object of that class. So, instead of having to write one Collection class for Integers, another for Strings, another for Shapes, etc., using generics allows a single class to support multiple types, which enables the class to be utilized to a much greater extent.

=== Mixins/Modules ===

In Ruby, classes and modules can be combined to provide a [http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ "mixin"]. Modules are code blocks which define methods which are not directly associate with a particular class:

module Greeter
def sayHi(name)
puts "Hi $#{@name}"
end

module Shouter
def yellHello(name)
puts "HELLO $#{@name}"
end

As you can see, sayHi and YellHello are methods with implementations, but they are not associated with a specific class. These modules can be associated with a class in one of two ways. Through the class definition:

class Talker
include Greeter
extend Shouter
...
end

class TalkerToo
...
end

...or an instance of the class can be mixed at runtime:

ttoo = TalkerToo.new
ttoo.extend Shouter
ttoo.include Greeter

Extending a class or instance with a module adds the methods as class methods. Including a class or instance with a module adds the methods as instance methods.

The Ruby language provides some specific modules that can be used to extend classes such as [http://www.ruby-doc.org/core/classes/Comparable.html Comparable] and [http://www.ruby-doc.org/core/classes/Enumerable.html Enumerable].

=== Aspect ===

[http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-oriented programming] is a methodology which supports the separation of concerns for a program feature which would normally have to intrude into several different modules which are not related to that feature. A common example of a cross-cutting concern is logging program execution, where every method entry and exit may warrant a message added to a log file. By using an aspect, the logging function can be defined outside of the implementation of the rest of the program, leaving the rest of the implementation decoupled from the logging implementation.

Aspect mechanisms are available for both Ruby and Java:
* For Ruby there is [http://aspectr.sourceforge.net/ AspectR] and [http://aquarium.rubyforge.org/ Aquarium]. Both are provided as modules which are included within the target implementation.
* For Java, one of the leading mechanisms is [http://www.eclipse.org/aspectj/ AspectJ] which is an Eclipse-homed implementation. Additional tooling, called [http://www.eclipse.org/ajdt/ AJDT], is provided as well.
* Several [http://java-source.net/open-source/aspect-oriented-frameworks AOP Frameworks for Java] are available.

Although touted as a method for separation of concerns, aspects also provide a way for programmers to provide a set of code which interacts broadly across a system, and thus reuse of the either the aspect or the functions within a system is achieved, similarly to how function or method calls achieve code reuse.

== Comparing the Various Mechanisms ==

{| style="background:silver; color:blue" border="1" cellpadding="2"
!width="100"|Reuse Mechanism
!width="200"|Simplicity/Complexity
!width="200"|Versatility
!width="200"|Performance/Efficiency
|- style="background:white; color:black"
|Cut & Paste || Extremely easy to implement || Not very versatile; requires careful attention in editing; changes in function require understanding of implementation || Highly inefficient; potential to have multiple copies of the same code throughout system
|- style="background:white; color:black"
| Include || Very easy to implement || Not versatile; potentially requires detail knowledge of the entity being included || Poor performance; the include is effectively cut and paste without the cognitive baggage
|- style="background:white; color:black"
| Gosub|| Very easy to implement || Can be versatile through use of global variables as switches, however subroutine loose cohesion || Somewhat more efficient than cut and paste and include in terms of memory and program size; variables are "passed" via global means
|- style="background:white; color:black"
| Procedures || Easy to implement || Fairly versatile though use of parameters || More efficient than gosub: Parameters provide local variables (on the stack) to the procedure, and potentially save global memory.
|- style="background:white; color:black"
| Functions || Easy to implement || Slightly more versatile with addition of return value in addition to parameters || Similar to procedures
|- style="background:white; color:black"
| Methods || Fairly easy to implement || Can be highly versatile, especially if well designed and associate class and method are self-documenting, providing ease-of-use || Although there may be several instances of an object being used, the methods associated with those objects generally occupy a single space in memory providing for efficient performance.
|- style="background:white; color:black"
| Inheritance || Takes some thought to do well || Somewhat versatile, but to be well-designed, the subclasses must relate well to the superclass || Should provide an additional layer of efficiency since some methods can be shared by multiple classes
|- style="background:white; color:black"
| Polymorphism || Somewhat difficult to implement well || If well designed, polymorphism adds a layer of versatility over just plain inheritance: The consumer has less concern about the specifics being implemented by the method being called || Polymorphism requires run-time identification of objects to determine what method should actually be executed, and this factor can reduce performance, however depending on the compiler, [http://www.javaspecialists.eu/archive/Issue158.html it cannot be assumed that polymorphism always affects performance negatively].
|- style="background:white; color:black"
| Generics || Moderately difficult to use and takes careful design to implement well || Can be highly versatile; When designed correctly, source code that is agnostic to object types can be reused by multiple objects || Sun's Java [http://java.sun.com/developer/technicalArticles/J2SE/generics/ implements generics] via parameter passing of the generic type whereas C++ uses a macro-based mechanism to replace the type in the original generic source. In this fashion, the Java version of generics produces a smaller footprint than C++.
|- style="background:white; color:black"
| Mixins/Modules || Not difficult to implement, but careful thought is needed to make highly reusable || Can be highly versatile, providing common methods to a few classes or instances, or providing a broader capability akin to aspects || From a coding perspective, can be highly effective; Mixins, as well as the nature of [http://www.joelonsoftware.com/items/2006/09/12.html |an interpretive late-binding language and duck typing] don't bode well for performance compared to other methods
|- style="background:white; color:black"
| Aspects || Can be difficult to implement well || Not very versatile, focused primarily on cross-system features || From a coding perspective, can be highly efficient; From a system execution perspective, performance is dependent on implementation of aspect-capability
|}

== Encouraging Reuse ==

With all the various techniques available, code reuse is not universally embraced, either academically or commercially. [http://www.itstrategycenter.com/wbbm/Res/analytics/black_art_of_reusing_software/index.html CIO Strategy Center] recommends 4 key actions to encourage code reuse in a company:

* Build a business case to get buy-in from the organization's business leaders.
* Establish repeatable, practical processes which reduce the potential roadblocks in developing reusable code.
* Focus on ways the design process can facilitate code reuse.
* Shift the business culture to a reuse mindset.

From an academic perspective, encouraging code reuse can be tricky, especially given concerns about maintaining academic integrity. One way education institutions are doing both is through encouraging students to participate in [http://arstechnica.com/open-source/news/2009/06/academic-source-code-dust-up-symptom-of-cs-education-ills.ars open source projects].

== Conclusion ==

Software reuse can take many forms, with those forms offering many levels of complexity and utility. With careful planning and thoughtful design, software reuse has the potential to speed development time and improve software reliability.

== References ==

* Brooks, Jr., F.P. ''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month The Mythical Man-Month]''. Boston, MA: Addison Wesley Longman, Inc., 1995.
* [http://sourcemaking.com/antipatterns/cut-and-paste-programming Cut-and-Paste Programming]

CSC/ECE 517 Fall 2009/wiki2 7 co

2009-10-14T00:48:43Z

Catowner: /* Comparing the Various Mechanisms */

== Code Reuse Methods and Mechanisms ==

''The best way to attack the essence of building software is not to build it at all.''
- [http://en.wikipedia.org/wiki/Fred_Brooks Fredrick P. Brooks, Jr.],''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month The Mythical Man-Month]''

In his 1975 classic, ''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month The Mythical Man-Month]'', [http://en.wikipedia.org/wiki/Fred_Brooks Fred Brooks] claimed that the implementation of design (what he called "accidental tasks") was essentially efficient enough that improvements in that area would not result in significant gains in productivity. Twenty years later, in a follow-up edition, he refined and clarified his view. He recognized that the rise of object-oriented languages and methodologies had the potential and promise of easy reuse, although he was still skeptical of dramatic productivity claims. Fundamentally, though, he saw that overall software development productivity can be enhanced through reuse.

This page will review some of the different techniques that are available for code reuse, and then a comparison of the techniques will be presented.

== Code Reuse Through Direct Code Use ==

There are several classic code reuse mechanisms which work at the fundamental source code level. This section will discuss this class of mechanisms.

=== Cut & Paste ===

One of the most basic reuse mechanism is the cut and paste method. Simply find the source code that performs the function that is required and copy the code into the place it is needed. This method can be implemented either by copying from some external source, such as a book or another software program, or by duplicating the same code within the same program. The latter method is generally a [http://sourcemaking.com/antipatterns/cut-and-paste-programming very discouraged practice]. Additionally, using this method can lead to [http://en.wikipedia.org/wiki/Copy_and_paste_programming plagiarism].

=== Includes ===

In C and C++, the '''includes''' construct places the contents of the file specified in the include parameter in the spot where the include is placed:

#include "time.h"

class Time
{...

In this example, the compiler effectively copies the code within time.h at the point where the #include statement is declared. Nearly all compilers will provide for specifying paths to search for the indicated file and provide rules or conventions for dealing with multiple occurrences of the same file.

== Code Reuse through Subroutines ==

This section explores code reuse mechanisms that involve executing common blocks of code that can provide utility or common operations.

=== Gosub ===

In [http://www.vintage-basic.net/ Vintage Basic] (comparable to the Basic language dialects from the late 70s and early 80s), individual lines of code are designated by line numbers. Blocks of code can be designated as subroutines and the '''GOSUB''' command can jump to these blocks of code. Execution jumps back to the line following the GOSUB command once a '''RETURN''' is encountered in the subroutine:

10 FOR I=1 TO 5
20 GOSUB 100
30 NEXT I
40 END
100 PRINT "Value = "; I
110 RETURN

Note that in this construct, parameters are not passed to the subroutine, but since all variables were global, parameters could still be simulated through careful use of global variables.

=== Procedures ===

In Pascal, '''procedures''' provided a way to jump to a block of code, and parameters can be passed to that block as well:

var j:Integer;

procedure PrintValue(i: Integer);
begin
Write("Value = ");
Writeln(i);
end;

begin
for j := 1 to 5 do
PrintValue(j)
end.

In this scheme, in order to update parameters with actions performed within the procedure, a parameter must be [http://www.arl.wustl.edu/~lockwood/class/cs306/books/artofasm/Chapter_11/CH11-2.html#HEADING2-29 '''passed by reference'''], effectively passing the memory address of the parameter so it can be effected directly.

=== Functions ===

Pascal also includes a construct called '''functions''' which allow a subroutine to return a value to the caller:

var j:Integer;

function Square(i: Integer): Integer;
begin
Square = i * i;
end;

begin
for j := 1 to 5 do
Writeln("Square of ", j, " = ", Square(j));
end.

Although a similar construct can be created using procedures, functions allow for more concise coding.

== Code Reuse through Extension ==

Many languages allow existing code to be reused through extensions that leave the original code unaltered. This section explores those mechanisms.

=== Methods ===

'''Methods''' (in [http://java.sun.com/docs/books/tutorial/java/javaOO/methods.html Java] and [http://www.cplusplus.com/doc/tutorial/classes/ C++]) are functions which are encapsulated within a class structure. The class structure can provide a level of data and implementation hiding which can facilitate better design.

public class Square {
int size;
...
public void draw() {
...
}
}

In and of themselves, methods do not offer any additional capability over functions, but operating within a class structure, several object-oriented paradigms can make methods more effective for code reuse.

=== Inheritance ===

'''Inheritance''' is an object-oriented concept which allows a developer to create subclasses of a base class which can refine or expand the base class.

public class Rectangle {
int width, height;
public Rectangle(int w, int h) {
...
}
...
}

public class Square extends Rectangle {
int size;
public Square(int s) {
super(s,s);
...
}
...
}

In this example, the Square class extend the Rectangle class. In the Square constructor, the Rectangle constructor is called and, thus, is reused.

Using inheritance, base classes can hold much of the common elements that are used by the subclasses. Code is reused by the subclasses through the common base class.

=== Polymorphism ===

'''Polymorphism''' is another object-oriented concept which allows a developer to reuse a defined interface in a class, but provide for an implementation that is specialized to that specific class.

abstract public class Shape {
abstract public void draw();
}

public class Square extends Shape {
public draw() {
...
}
}

public class Circle extends Shape {
public draw() {
...
}
}

In this example, the draw method has been indicated in the Shape class, but implemented in the subclasses Square and Circle. This example may not seem like code reuse, but it can be argued that the concept around providing a common signature for the subclasses is a type of reuse. Further, polymorphism provides one of the key foundations for object-oriented programming.

=== Generics ===

'''Generics''' in Java and C++ provide a mechanism where a type or class (such as String, int, or Shape) can be provided to a method as a parameter. In this fashion, the generic method can accommodate multiple types, or they can be used to catch potential typing issues at compile time that might otherwise be missed.

* [http://java.sun.com/docs/books/tutorial/extra/generics/index.html Tutorial on Generics in Java]
* [http://msdn.microsoft.com/en-us/library/c570k3f3%28VS.80%29.aspx Overview of Generics in Visual C++]

One example of generics in Java is in the java.util class for [http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html collection classes]. In the declaration for the Collection class, the type is declared in angle brackets ("<Type>") and is implicitly provided as a parameter to the class and instance methods for an object of that class. So, instead of having to write one Collection class for Integers, another for Strings, another for Shapes, etc., using generics allows a single class to support multiple types, which enables the class to be utilized to a much greater extent.

=== Mixins/Modules ===

In Ruby, classes and modules can be combined to provide a [http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ "mixin"]. Modules are code blocks which define methods which are not directly associate with a particular class:

module Greeter
def sayHi(name)
puts "Hi $#{@name}"
end

module Shouter
def yellHello(name)
puts "HELLO $#{@name}"
end

As you can see, sayHi and YellHello are methods with implementations, but they are not associated with a specific class. These modules can be associated with a class in one of two ways. Through the class definition:

class Talker
include Greeter
extend Shouter
...
end

class TalkerToo
...
end

...or an instance of the class can be mixed at runtime:

ttoo = TalkerToo.new
ttoo.extend Shouter
ttoo.include Greeter

Extending a class or instance with a module adds the methods as class methods. Including a class or instance with a module adds the methods as instance methods.

The Ruby language provides some specific modules that can be used to extend classes such as [http://www.ruby-doc.org/core/classes/Comparable.html Comparable] and [http://www.ruby-doc.org/core/classes/Enumerable.html Enumerable].

=== Aspect ===

[http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-oriented programming] is a methodology which supports the separation of concerns for a program feature which would normally have to intrude into several different modules which are not related to that feature. A common example of a cross-cutting concern is logging program execution, where every method entry and exit may warrant a message added to a log file. By using an aspect, the logging function can be defined outside of the implementation of the rest of the program, leaving the rest of the implementation decoupled from the logging implementation.

Aspect mechanisms are available for both Ruby and Java:
* For Ruby there is [http://aspectr.sourceforge.net/ AspectR] and [http://aquarium.rubyforge.org/ Aquarium]. Both are provided as modules which are included within the target implementation.
* For Java, one of the leading mechanisms is [http://www.eclipse.org/aspectj/ AspectJ] which is an Eclipse-homed implementation. Additional tooling, called [http://www.eclipse.org/ajdt/ AJDT], is provided as well.
* Several [http://java-source.net/open-source/aspect-oriented-frameworks AOP Frameworks for Java] are available.

Although touted as a method for separation of concerns, aspects also provide a way for programmers to provide a set of code which interacts broadly across a system, and thus reuse of the either the aspect or the functions within a system is achieved, similarly to how function or method calls achieve code reuse.

== Comparing the Various Mechanisms ==

{| style="background:silver; color:blue" border="1" cellpadding="2"
!width="100"|Reuse Mechanism
!width="200"|Simplicity/Complexity
!width="200"|Versatility
!width="200"|Performance/Efficiency
|- style="background:white; color:black"
|Cut & Paste || Extremely easy to implement || Not very versatile; requires careful attention in editing; changes in function require understanding of implementation || Highly inefficient; potential to have multiple copies of the same code throughout system
|- style="background:white; color:black"
| Include || Very easy to implement || Not versatile; potentially requires detail knowledge of the entity being included || Poor performance; the include is effectively cut and paste without the cognitive baggage
|- style="background:white; color:black"
| Gosub|| Very easy to implement || Can be versatile through use of global variables as switches, however subroutine loose cohesion || Somewhat more efficient than cut and paste and include in terms of memory and program size; variables are "passed" via global means
|- style="background:white; color:black"
| Procedures || Easy to implement || Fairly versatile though use of parameters || More efficient than gosub: Parameters provide local variables (on the stack) to the procedure, and potentially save global memory.
|- style="background:white; color:black"
| Functions || Easy to implement || Slightly more versatile with addition of return value in addition to parameters || Similar to procedures
|- style="background:white; color:black"
| Methods || Fairly easy to implement || Can be highly versatile, especially if well designed and associate class and method are self-documenting, providing ease-of-use || Although there may be several instances of an object being used, the methods associated with those objects generally occupy a single space in memory providing for efficient performance.
|- style="background:white; color:black"
| Inheritance || Takes some thought to do well || Somewhat versatile, but to be well-designed, the subclasses must relate well to the superclass || Should provide an additional layer of efficiency since some methods can be shared by multiple classes
|- style="background:white; color:black"
| Polymorphism || Somewhat difficult to implement well || If well designed, polymorphism adds a layer of versatility over just plain inheritance: The consumer has less concern about the specifics being implemented by the method being called || Polymorphism requires run-time identification of objects to determine what method should actually be executed, and this factor can reduce performance, however depending on the compiler, [http://www.javaspecialists.eu/archive/Issue158.html it cannot be assumed that polymorphism always affects performance negatively].
|- style="background:white; color:black"
| Generics || Moderately difficult to use and takes careful design to implement well || Can be highly versatile; When designed correctly, source code that is agnostic to object types can be reused by multiple objects || Sun's Java [http://java.sun.com/developer/technicalArticles/J2SE/generics/ implements generics] via parameter passing of the generic type whereas C++ uses a macro-based mechanism to replace the type in the original generic source. In this fashion, the Java version of generics produces a smaller footprint than C++.
|- style="background:white; color:black"
| Mixins/Modules || Not difficult to implement, but careful thought is needed to make highly reusable || Can be highly versatile, providing common methods to a few classes or instances, or providing a broader capability akin to aspects || From a coding perspective, can be highly effective; Mixins, as well as the nature of [http://www.joelonsoftware.com/items/2006/09/12.html |an interpretive late-binding language and duck typing] don't bode well for performance compared to other methods
|- style="background:white; color:black"
| Aspects || Can be difficult to implement well || Not very versatile, focused primarily on cross-system features || From a coding perspective, can be highly efficient; From a system execution perspective, performance is dependent on implementation of aspect-capability
|}

== Encouraging Reuse ==

With all the various techniques available, code reuse is not universally embraced, either academically or commercially. [http://www.itstrategycenter.com/wbbm/Res/analytics/black_art_of_reusing_software/index.html CIO Strategy Center] recommends 4 key actions to encourage code reuse in a company:

* Build a business case to get buy-in from the organization's business leaders.
* Establish repeatable, practical processes which reduce the potential roadblocks in developing reusable code.
* Focus on ways the design process can facilitate code reuse.
* Shift the business culture to a reuse mindset.

From an academic perspective, encouraging code reuse can be tricky, especially given concerns about maintaining academic integrity. One way education institutions are doing both is through encouraging students to participate in [http://arstechnica.com/open-source/news/2009/06/academic-source-code-dust-up-symptom-of-cs-education-ills.ars open source projects].

== Conclusion ==

Conclusion needed

== References ==

* Brooks, Jr., F.P. ''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month The Mythical Man-Month]''. Boston, MA: Addison Wesley Longman, Inc., 1995.
* [http://sourcemaking.com/antipatterns/cut-and-paste-programming Cut-and-Paste Programming]

CSC/ECE 517 Fall 2009/wiki2 7 co

2009-10-14T00:29:24Z

Catowner: /* Comparing the Various Mechanisms */

== Code Reuse Methods and Mechanisms ==

''The best way to attack the essence of building software is not to build it at all.''
- [http://en.wikipedia.org/wiki/Fred_Brooks Fredrick P. Brooks, Jr.],''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month The Mythical Man-Month]''

In his 1975 classic, ''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month The Mythical Man-Month]'', [http://en.wikipedia.org/wiki/Fred_Brooks Fred Brooks] claimed that the implementation of design (what he called "accidental tasks") was essentially efficient enough that improvements in that area would not result in significant gains in productivity. Twenty years later, in a follow-up edition, he refined and clarified his view. He recognized that the rise of object-oriented languages and methodologies had the potential and promise of easy reuse, although he was still skeptical of dramatic productivity claims. Fundamentally, though, he saw that overall software development productivity can be enhanced through reuse.

This page will review some of the different techniques that are available for code reuse, and then a comparison of the techniques will be presented.

== Code Reuse Through Direct Code Use ==

There are several classic code reuse mechanisms which work at the fundamental source code level. This section will discuss this class of mechanisms.

=== Cut & Paste ===

One of the most basic reuse mechanism is the cut and paste method. Simply find the source code that performs the function that is required and copy the code into the place it is needed. This method can be implemented either by copying from some external source, such as a book or another software program, or by duplicating the same code within the same program. The latter method is generally a [http://sourcemaking.com/antipatterns/cut-and-paste-programming very discouraged practice]. Additionally, using this method can lead to [http://en.wikipedia.org/wiki/Copy_and_paste_programming plagiarism].

=== Includes ===

In C and C++, the '''includes''' construct places the contents of the file specified in the include parameter in the spot where the include is placed:

#include "time.h"

class Time
{...

In this example, the compiler effectively copies the code within time.h at the point where the #include statement is declared. Nearly all compilers will provide for specifying paths to search for the indicated file and provide rules or conventions for dealing with multiple occurrences of the same file.

== Code Reuse through Subroutines ==

This section explores code reuse mechanisms that involve executing common blocks of code that can provide utility or common operations.

=== Gosub ===

In [http://www.vintage-basic.net/ Vintage Basic] (comparable to the Basic language dialects from the late 70s and early 80s), individual lines of code are designated by line numbers. Blocks of code can be designated as subroutines and the '''GOSUB''' command can jump to these blocks of code. Execution jumps back to the line following the GOSUB command once a '''RETURN''' is encountered in the subroutine:

10 FOR I=1 TO 5
20 GOSUB 100
30 NEXT I
40 END
100 PRINT "Value = "; I
110 RETURN

Note that in this construct, parameters are not passed to the subroutine, but since all variables were global, parameters could still be simulated through careful use of global variables.

=== Procedures ===

In Pascal, '''procedures''' provided a way to jump to a block of code, and parameters can be passed to that block as well:

var j:Integer;

procedure PrintValue(i: Integer);
begin
Write("Value = ");
Writeln(i);
end;

begin
for j := 1 to 5 do
PrintValue(j)
end.

In this scheme, in order to update parameters with actions performed within the procedure, a parameter must be [http://www.arl.wustl.edu/~lockwood/class/cs306/books/artofasm/Chapter_11/CH11-2.html#HEADING2-29 '''passed by reference'''], effectively passing the memory address of the parameter so it can be effected directly.

=== Functions ===

Pascal also includes a construct called '''functions''' which allow a subroutine to return a value to the caller:

var j:Integer;

function Square(i: Integer): Integer;
begin
Square = i * i;
end;

begin
for j := 1 to 5 do
Writeln("Square of ", j, " = ", Square(j));
end.

Although a similar construct can be created using procedures, functions allow for more concise coding.

== Code Reuse through Extension ==

Many languages allow existing code to be reused through extensions that leave the original code unaltered. This section explores those mechanisms.

=== Methods ===

'''Methods''' (in [http://java.sun.com/docs/books/tutorial/java/javaOO/methods.html Java] and [http://www.cplusplus.com/doc/tutorial/classes/ C++]) are functions which are encapsulated within a class structure. The class structure can provide a level of data and implementation hiding which can facilitate better design.

public class Square {
int size;
...
public void draw() {
...
}
}

In and of themselves, methods do not offer any additional capability over functions, but operating within a class structure, several object-oriented paradigms can make methods more effective for code reuse.

=== Inheritance ===

'''Inheritance''' is an object-oriented concept which allows a developer to create subclasses of a base class which can refine or expand the base class.

public class Rectangle {
int width, height;
public Rectangle(int w, int h) {
...
}
...
}

public class Square extends Rectangle {
int size;
public Square(int s) {
super(s,s);
...
}
...
}

In this example, the Square class extend the Rectangle class. In the Square constructor, the Rectangle constructor is called and, thus, is reused.

Using inheritance, base classes can hold much of the common elements that are used by the subclasses. Code is reused by the subclasses through the common base class.

=== Polymorphism ===

'''Polymorphism''' is another object-oriented concept which allows a developer to reuse a defined interface in a class, but provide for an implementation that is specialized to that specific class.

abstract public class Shape {
abstract public void draw();
}

public class Square extends Shape {
public draw() {
...
}
}

public class Circle extends Shape {
public draw() {
...
}
}

In this example, the draw method has been indicated in the Shape class, but implemented in the subclasses Square and Circle. This example may not seem like code reuse, but it can be argued that the concept around providing a common signature for the subclasses is a type of reuse. Further, polymorphism provides one of the key foundations for object-oriented programming.

=== Generics ===

'''Generics''' in Java and C++ provide a mechanism where a type or class (such as String, int, or Shape) can be provided to a method as a parameter. In this fashion, the generic method can accommodate multiple types, or they can be used to catch potential typing issues at compile time that might otherwise be missed.

* [http://java.sun.com/docs/books/tutorial/extra/generics/index.html Tutorial on Generics in Java]
* [http://msdn.microsoft.com/en-us/library/c570k3f3%28VS.80%29.aspx Overview of Generics in Visual C++]

One example of generics in Java is in the java.util class for [http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html collection classes]. In the declaration for the Collection class, the type is declared in angle brackets ("<Type>") and is implicitly provided as a parameter to the class and instance methods for an object of that class. So, instead of having to write one Collection class for Integers, another for Strings, another for Shapes, etc., using generics allows a single class to support multiple types, which enables the class to be utilized to a much greater extent.

=== Mixins/Modules ===

In Ruby, classes and modules can be combined to provide a [http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ "mixin"]. Modules are code blocks which define methods which are not directly associate with a particular class:

module Greeter
def sayHi(name)
puts "Hi $#{@name}"
end

module Shouter
def yellHello(name)
puts "HELLO $#{@name}"
end

As you can see, sayHi and YellHello are methods with implementations, but they are not associated with a specific class. These modules can be associated with a class in one of two ways. Through the class definition:

class Talker
include Greeter
extend Shouter
...
end

class TalkerToo
...
end

...or an instance of the class can be mixed at runtime:

ttoo = TalkerToo.new
ttoo.extend Shouter
ttoo.include Greeter

Extending a class or instance with a module adds the methods as class methods. Including a class or instance with a module adds the methods as instance methods.

The Ruby language provides some specific modules that can be used to extend classes such as [http://www.ruby-doc.org/core/classes/Comparable.html Comparable] and [http://www.ruby-doc.org/core/classes/Enumerable.html Enumerable].

=== Aspect ===

[http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-oriented programming] is a methodology which supports the separation of concerns for a program feature which would normally have to intrude into several different modules which are not related to that feature. A common example of a cross-cutting concern is logging program execution, where every method entry and exit may warrant a message added to a log file. By using an aspect, the logging function can be defined outside of the implementation of the rest of the program, leaving the rest of the implementation decoupled from the logging implementation.

Aspect mechanisms are available for both Ruby and Java:
* For Ruby there is [http://aspectr.sourceforge.net/ AspectR] and [http://aquarium.rubyforge.org/ Aquarium]. Both are provided as modules which are included within the target implementation.
* For Java, one of the leading mechanisms is [http://www.eclipse.org/aspectj/ AspectJ] which is an Eclipse-homed implementation. Additional tooling, called [http://www.eclipse.org/ajdt/ AJDT], is provided as well.
* Several [http://java-source.net/open-source/aspect-oriented-frameworks AOP Frameworks for Java] are available.

Although touted as a method for separation of concerns, aspects also provide a way for programmers to provide a set of code which interacts broadly across a system, and thus reuse of the either the aspect or the functions within a system is achieved, similarly to how function or method calls achieve code reuse.

== Comparing the Various Mechanisms ==

{| style="background:silver; color:blue" border="1" cellpadding="2"
!width="100"|Reuse Mechanism
!width="200"|Simplicity/Complexity
!width="200"|Versatility
!width="200"|Performance/Efficiency
|- style="background:white; color:black"
|Cut & Paste || Extremely easy to implement || Not very versatile; requires careful attention in editing; changes in function require understanding of implementation || Highly inefficient; potential to have multiple copies of the same code throughout system
|- style="background:white; color:black"
| Include || Very easy to implement || Not versatile; potentially requires detail knowledge of the entity being included || Poor performance; the include is effectively cut and paste without the cognitive baggage
|- style="background:white; color:black"
| Gosub|| Very easy to implement || Can be versatile through use of global variables as switches, however subroutine loose cohesion || Somewhat more efficient than cut and paste and include in terms of memory and program size; variables are "passed" via global means
|- style="background:white; color:black"
| Procedures || Easy to implement || x || x
|- style="background:white; color:black"
| Functions || Easy to implement || x || x
|- style="background:white; color:black"
| Methods || Fairly easy to implement || x || x
|- style="background:white; color:black"
| Inheritance || Takes some thought to do well || x || x
|- style="background:white; color:black"
| Polymorphism || Somewhat difficult to implement well || x || x
|- style="background:white; color:black"
| Generics || Moderately difficult to use and takes careful design to implement well || Can be highly versatile; When designed correctly, source code that is agnostic to object types can be reused by multiple objects || Sun's Java [http://java.sun.com/developer/technicalArticles/J2SE/generics/ implements generics] via parameter passing of the generic type whereas C++ uses a macro-based mechanism to replace the type in the original generic source. In this fashion, the Java version of generics produces a smaller footprint than C++.
|- style="background:white; color:black"
| Mixins/Modules || Not difficult to implement, but careful thought is needed to make highly reusable || Can be highly versatile, providing common methods to a few classes or instances, or providing a broader capability akin to aspects || From a coding perspective, can be highly effective; Mixins, as well as the nature of [http://www.joelonsoftware.com/items/2006/09/12.html |an interpretive late-binding language and duck typing] don't bode well for performance compared to other methods
|- style="background:white; color:black"
| Aspects || Can be difficult to implement well || Not very versatile, focused primarily on cross-system features || From a coding perspective, can be highly efficient; From a system execution perspective, performance is dependent on implementation of aspect-capability
|}

== Encouraging Reuse ==

With all the various techniques available, code reuse is not universally embraced, either academically or commercially. [http://www.itstrategycenter.com/wbbm/Res/analytics/black_art_of_reusing_software/index.html CIO Strategy Center] recommends 4 key actions to encourage code reuse in a company:

* Build a business case to get buy-in from the organization's business leaders.
* Establish repeatable, practical processes which reduce the potential roadblocks in developing reusable code.
* Focus on ways the design process can facilitate code reuse.
* Shift the business culture to a reuse mindset.

From an academic perspective, encouraging code reuse can be tricky, especially given concerns about maintaining academic integrity. One way education institutions are doing both is through encouraging students to participate in [http://arstechnica.com/open-source/news/2009/06/academic-source-code-dust-up-symptom-of-cs-education-ills.ars open source projects].

== Conclusion ==

Conclusion needed

== References ==

* Brooks, Jr., F.P. ''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month The Mythical Man-Month]''. Boston, MA: Addison Wesley Longman, Inc., 1995.
* [http://sourcemaking.com/antipatterns/cut-and-paste-programming Cut-and-Paste Programming]

CSC/ECE 517 Fall 2009/wiki2 7 co

2009-10-14T00:05:54Z

Catowner: /* Comparing the Various Mechanisms */

== Code Reuse Methods and Mechanisms ==

''The best way to attack the essence of building software is not to build it at all.''
- [http://en.wikipedia.org/wiki/Fred_Brooks Fredrick P. Brooks, Jr.],''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month The Mythical Man-Month]''

In his 1975 classic, ''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month The Mythical Man-Month]'', [http://en.wikipedia.org/wiki/Fred_Brooks Fred Brooks] claimed that the implementation of design (what he called "accidental tasks") was essentially efficient enough that improvements in that area would not result in significant gains in productivity. Twenty years later, in a follow-up edition, he refined and clarified his view. He recognized that the rise of object-oriented languages and methodologies had the potential and promise of easy reuse, although he was still skeptical of dramatic productivity claims. Fundamentally, though, he saw that overall software development productivity can be enhanced through reuse.

This page will review some of the different techniques that are available for code reuse, and then a comparison of the techniques will be presented.

== Code Reuse Through Direct Code Use ==

There are several classic code reuse mechanisms which work at the fundamental source code level. This section will discuss this class of mechanisms.

=== Cut & Paste ===

One of the most basic reuse mechanism is the cut and paste method. Simply find the source code that performs the function that is required and copy the code into the place it is needed. This method can be implemented either by copying from some external source, such as a book or another software program, or by duplicating the same code within the same program. The latter method is generally a [http://sourcemaking.com/antipatterns/cut-and-paste-programming very discouraged practice]. Additionally, using this method can lead to [http://en.wikipedia.org/wiki/Copy_and_paste_programming plagiarism].

=== Includes ===

In C and C++, the '''includes''' construct places the contents of the file specified in the include parameter in the spot where the include is placed:

#include "time.h"

class Time
{...

In this example, the compiler effectively copies the code within time.h at the point where the #include statement is declared. Nearly all compilers will provide for specifying paths to search for the indicated file and provide rules or conventions for dealing with multiple occurrences of the same file.

== Code Reuse through Subroutines ==

This section explores code reuse mechanisms that involve executing common blocks of code that can provide utility or common operations.

=== Gosub ===

In [http://www.vintage-basic.net/ Vintage Basic] (comparable to the Basic language dialects from the late 70s and early 80s), individual lines of code are designated by line numbers. Blocks of code can be designated as subroutines and the '''GOSUB''' command can jump to these blocks of code. Execution jumps back to the line following the GOSUB command once a '''RETURN''' is encountered in the subroutine:

10 FOR I=1 TO 5
20 GOSUB 100
30 NEXT I
40 END
100 PRINT "Value = "; I
110 RETURN

Note that in this construct, parameters are not passed to the subroutine, but since all variables were global, parameters could still be simulated through careful use of global variables.

=== Procedures ===

In Pascal, '''procedures''' provided a way to jump to a block of code, and parameters can be passed to that block as well:

var j:Integer;

procedure PrintValue(i: Integer);
begin
Write("Value = ");
Writeln(i);
end;

begin
for j := 1 to 5 do
PrintValue(j)
end.

In this scheme, in order to update parameters with actions performed within the procedure, a parameter must be [http://www.arl.wustl.edu/~lockwood/class/cs306/books/artofasm/Chapter_11/CH11-2.html#HEADING2-29 '''passed by reference'''], effectively passing the memory address of the parameter so it can be effected directly.

=== Functions ===

Pascal also includes a construct called '''functions''' which allow a subroutine to return a value to the caller:

var j:Integer;

function Square(i: Integer): Integer;
begin
Square = i * i;
end;

begin
for j := 1 to 5 do
Writeln("Square of ", j, " = ", Square(j));
end.

Although a similar construct can be created using procedures, functions allow for more concise coding.

== Code Reuse through Extension ==

Many languages allow existing code to be reused through extensions that leave the original code unaltered. This section explores those mechanisms.

=== Methods ===

'''Methods''' (in [http://java.sun.com/docs/books/tutorial/java/javaOO/methods.html Java] and [http://www.cplusplus.com/doc/tutorial/classes/ C++]) are functions which are encapsulated within a class structure. The class structure can provide a level of data and implementation hiding which can facilitate better design.

public class Square {
int size;
...
public void draw() {
...
}
}

In and of themselves, methods do not offer any additional capability over functions, but operating within a class structure, several object-oriented paradigms can make methods more effective for code reuse.

=== Inheritance ===

'''Inheritance''' is an object-oriented concept which allows a developer to create subclasses of a base class which can refine or expand the base class.

public class Rectangle {
int width, height;
public Rectangle(int w, int h) {
...
}
...
}

public class Square extends Rectangle {
int size;
public Square(int s) {
super(s,s);
...
}
...
}

In this example, the Square class extend the Rectangle class. In the Square constructor, the Rectangle constructor is called and, thus, is reused.

Using inheritance, base classes can hold much of the common elements that are used by the subclasses. Code is reused by the subclasses through the common base class.

=== Polymorphism ===

'''Polymorphism''' is another object-oriented concept which allows a developer to reuse a defined interface in a class, but provide for an implementation that is specialized to that specific class.

abstract public class Shape {
abstract public void draw();
}

public class Square extends Shape {
public draw() {
...
}
}

public class Circle extends Shape {
public draw() {
...
}
}

In this example, the draw method has been indicated in the Shape class, but implemented in the subclasses Square and Circle. This example may not seem like code reuse, but it can be argued that the concept around providing a common signature for the subclasses is a type of reuse. Further, polymorphism provides one of the key foundations for object-oriented programming.

=== Generics ===

'''Generics''' in Java and C++ provide a mechanism where a type or class (such as String, int, or Shape) can be provided to a method as a parameter. In this fashion, the generic method can accommodate multiple types, or they can be used to catch potential typing issues at compile time that might otherwise be missed.

* [http://java.sun.com/docs/books/tutorial/extra/generics/index.html Tutorial on Generics in Java]
* [http://msdn.microsoft.com/en-us/library/c570k3f3%28VS.80%29.aspx Overview of Generics in Visual C++]

One example of generics in Java is in the java.util class for [http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html collection classes]. In the declaration for the Collection class, the type is declared in angle brackets ("<Type>") and is implicitly provided as a parameter to the class and instance methods for an object of that class. So, instead of having to write one Collection class for Integers, another for Strings, another for Shapes, etc., using generics allows a single class to support multiple types, which enables the class to be utilized to a much greater extent.

=== Mixins/Modules ===

In Ruby, classes and modules can be combined to provide a [http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ "mixin"]. Modules are code blocks which define methods which are not directly associate with a particular class:

module Greeter
def sayHi(name)
puts "Hi $#{@name}"
end

module Shouter
def yellHello(name)
puts "HELLO $#{@name}"
end

As you can see, sayHi and YellHello are methods with implementations, but they are not associated with a specific class. These modules can be associated with a class in one of two ways. Through the class definition:

class Talker
include Greeter
extend Shouter
...
end

class TalkerToo
...
end

...or an instance of the class can be mixed at runtime:

ttoo = TalkerToo.new
ttoo.extend Shouter
ttoo.include Greeter

Extending a class or instance with a module adds the methods as class methods. Including a class or instance with a module adds the methods as instance methods.

The Ruby language provides some specific modules that can be used to extend classes such as [http://www.ruby-doc.org/core/classes/Comparable.html Comparable] and [http://www.ruby-doc.org/core/classes/Enumerable.html Enumerable].

=== Aspect ===

[http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-oriented programming] is a methodology which supports the separation of concerns for a program feature which would normally have to intrude into several different modules which are not related to that feature. A common example of a cross-cutting concern is logging program execution, where every method entry and exit may warrant a message added to a log file. By using an aspect, the logging function can be defined outside of the implementation of the rest of the program, leaving the rest of the implementation decoupled from the logging implementation.

Aspect mechanisms are available for both Ruby and Java:
* For Ruby there is [http://aspectr.sourceforge.net/ AspectR] and [http://aquarium.rubyforge.org/ Aquarium]. Both are provided as modules which are included within the target implementation.
* For Java, one of the leading mechanisms is [http://www.eclipse.org/aspectj/ AspectJ] which is an Eclipse-homed implementation. Additional tooling, called [http://www.eclipse.org/ajdt/ AJDT], is provided as well.
* Several [http://java-source.net/open-source/aspect-oriented-frameworks AOP Frameworks for Java] are available.

Although touted as a method for separation of concerns, aspects also provide a way for programmers to provide a set of code which interacts broadly across a system, and thus reuse of the either the aspect or the functions within a system is achieved, similarly to how function or method calls achieve code reuse.

== Comparing the Various Mechanisms ==

{| style="background:silver; color:blue" border="1" cellpadding="2"
!width="100"|Reuse Mechanism
!width="200"|Simplicity/Complexity
!width="200"|Versatility
!width="200"|Performance/Efficiency
|- style="background:white; color:black"
|Cut & Paste || Extremely easy to implement || Not very versatile; requires careful attention in editing; changes in function require understanding of implementation || Highly inefficient; potential to have multiple copies of the same code throughout system
|- style="background:white; color:black"
| Include || Very easy to implement || Not versatile; potentially requires detail knowledge of the entity being included || Poor performance; the include is effectively cut and paste without the cognitive baggage
|- style="background:white; color:black"
| Gosub|| Very easy to implement || Can be versatile through use of global variables as switches, however subroutine loose cohesion || Somewhat more efficient than cut and paste and include in terms of memory and program size; variables are "passed" via global means
|- style="background:white; color:black"
| Procedures || x || x || x
|- style="background:white; color:black"
| Functions || x || x || x
|- style="background:white; color:black"
| Methods || x || x || x
|- style="background:white; color:black"
| Inheritance || x || x || x
|- style="background:white; color:black"
| Polymorphism || x || x || x
|- style="background:white; color:black"
| Generics || x || x || x
|- style="background:white; color:black"
| Mixins/Modules || x || x || x
|- style="background:white; color:black"
| Aspects || x || x || x
|}

== Encouraging Reuse ==

With all the various techniques available, code reuse is not universally embraced, either academically or commercially. [http://www.itstrategycenter.com/wbbm/Res/analytics/black_art_of_reusing_software/index.html CIO Strategy Center] recommends 4 key actions to encourage code reuse in a company:

* Build a business case to get buy-in from the organization's business leaders.
* Establish repeatable, practical processes which reduce the potential roadblocks in developing reusable code.
* Focus on ways the design process can facilitate code reuse.
* Shift the business culture to a reuse mindset.

From an academic perspective, encouraging code reuse can be tricky, especially given concerns about maintaining academic integrity. One way education institutions are doing both is through encouraging students to participate in [http://arstechnica.com/open-source/news/2009/06/academic-source-code-dust-up-symptom-of-cs-education-ills.ars open source projects].

== Conclusion ==

Conclusion needed

== References ==

* Brooks, Jr., F.P. ''[http://en.wikipedia.org/wiki/The_Mythical_Man-Month The Mythical Man-Month]''. Boston, MA: Addison Wesley Longman, Inc., 1995.
* [http://sourcemaking.com/antipatterns/cut-and-paste-programming Cut-and-Paste Programming]

CSC/ECE 517 Fall 2009/wiki2 7 co

2009-10-13T23:30:25Z

Catowner: /* Aspect */

CSC/ECE 517 Fall 2009/wiki2 7 co

2009-10-13T02:16:03Z

Catowner: /* Why Reuse Is Not Always Embraced */

CSC/ECE 517 Fall 2009/wiki2 7 co

2009-10-12T01:33:21Z

Catowner:

CSC/ECE 517 Fall 2009/wiki2 7 co

2009-10-12T01:00:16Z

Catowner:

CSC/ECE 517 Fall 2009/wiki2 7 co

2009-10-12T00:36:43Z

Catowner:

CSC/ECE 517 Fall 2009/wiki2 7 co

2009-10-11T00:48:25Z

Catowner:

CSC/ECE 517 Fall 2009/wiki1a 4 co

2009-09-07T19:32:22Z

Catowner:

== Best Practices For Source-Control Management With Version-Control Systems ==

“Tip 23: '''Always Use Source Code Control'''”
– Hunt and Thomas, The Pragmatic Programmer [HT 00]

In software development, change is almost always inevitable [P 05] . Using a source configuration management (SCM) system (also known as a Source Code Control System (SCCS) or version-control system) can help individuals and teams manage the changes that occur during the software development process [D 90]. This article will provide the reader with basic information, and direct the reader to additional reading for more in-depth consideration.

== Why Source Code Control is Necessary ==

According to Pressman, “Change is inevitable when computer software is built. [P 05]” He suggests four primary reasons for change:
* New business or market conditions
* New customer needs
* Reorganization, business growth, or downsizing
* Budgetary or scheduling constraints
Each of these reasons can cause changes in project requirements, in project priorities, or in the resources available to create or enhance a project. Managing the change with an SCM enables engineers to focus on technical work, and enables project managers to control changes which can affect project outcomes.

=== Links and Resources ===

These links and resources can help the reader further understand the need for source code control:
* http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf, pp. 176-178.
* Dart, S. [http://www.sei.cmu.edu/reports/90tr011.pdf “Spectrum of Functionality in Configuration Management Systems"], Software Engineering Institute, 1990. Review pp. 1-4.
* http://svnbook.red-bean.com/en/1.4/svn-book.html, review the Forward section.
* [http://betterexplained.com/articles/a-visual-guide-to-version-control/ A Visual Guide to Version Control]. Review the section titled “So Why Do We Need A Version Control System (VCS)?”
* Pressman, Roger S., Software Engineering: A Practitioner’s Approach, pp. 739-742, McGraw-Hill, New York, NY, 2005

== Understanding Basic Concepts ==

For the reader new to SCM, there are a few basic terms and concepts that should be understood before best practices are considered:
* '''Check-in''' or '''Commit''' – Writing changes to the source code repository
* [http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.basic.vsn-models.lock-unlock.dia-1 '''Lock-Modify-Unlock Model''']: An SCM model that requires a developer to reserve or lock a source file before making changes to the file. This lock prevents other developers from modifying the file.
* [http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.basic.vsn-models.copy-merge.dia-1 '''Change-Modify-Merge Model''']: An SCM model that allows multiple developers to make changes to a source file. Upon commit, if the source file has been updated by another developer, a merge of the updated file with the developers change is necessary in order to preserve all the updates. Depending on the SCM and the nature of the change, the merge operation may be performed by the SCM or by the developer.
* '''Revision''' – The version identifier of the source file (e.g. v1, v2, v2.1, etc). Each commit of a source file will produce a new revision value.
* '''Baseline''' – The root of a development stream, where changes that are intended to be integrated into the main project will eventually migrate.
* '''Branch''' – An offshoot from the baseline where prototype, testing, or other work can be performed that does not immediately affect the baseline. Eventually, a branch may be merged back into the baseline.

=== Links and Resources ===

These links can provide the reader with additional information on SCM vocabulary:

* [http://msmvps.com/blogs/peterritchie/archive/2009/03/11/developing-with-source-code-control-best-practices-part-2.aspx Developing with Source Code Control - Best Practices Part 2]: Review the '''Vocabulary''' section.
* [http://betterexplained.com/articles/a-visual-guide-to-version-control/ A Visual Guide to Version Control]: Review the '''Learn the Lingo''' section.
* [http://en.wikipedia.org/wiki/Source_Code_Management#Common_vocabulary Revision Control] in Wikipedia. Review the '''Common Vocabulary''' section.

== Advice on Using an SCM or SCCS ==

There is differing advice on using an SCM to manage projects, but there are some consistent messages:

* '''Use a source configuration management product:''' When working on teams, there is a general consensus that an SCM will greatly help the team manage changes. Further, Hunt and Thomas [HT 00] suggest that even an individual should use an SCM to manage their work, even if their team does not, because of its ability to archive work and to "undo" mistakes.
* '''Commit code changes frequently:''' Much of the advice suggests that source code should be [http://www.martinfowler.com/articles/continuousIntegration.html integrated on a regular basis], some even suggesting [http://www.extremeprogramming.org/rules/integrateoften.html checking-in code every few hours].
* '''In a Lock-Modify-Unlock model, check-out only what you need:''' [http://msdn.microsoft.com/en-us/library/ee371247%28Expression.30%29.aspx This advice] is probably obvious, but in the Lock-Modify-Unlock model, source files will be unavailable for others to update in the Lock phase, so keeping that number of files to a minimum reduces programming team "deadlocks". For development teams that have the maturity or tooling, a Change-Modify-Merge model reduces the concern about reserving files, but does not eliminate the potential issues (in particular, dealing with [http://msmvps.com/blogs/peterritchie/archive/2009/03/11/developing-with-source-code-control-best-practices-part-2.aspx merge conflicts]).
* '''Store tooling as well as source code in the SCM:''' Actually, much advice suggests storing [http://books.google.com/books?id=-2wqcKAq4tIC&pg=PA45&lpg=PA45&dq=source+code+control+best+practices even more artifacts], but in particular, if a software team wants to recreate a specific version of the software, it will likely be crucial to have access to the original tools that created that version, as well as the source code. See section 6 of the white paper [http://www.perforce.com/perforce/papers/bestpractices.html High-level Best Practices in Software Configuration Management] by Laura Wingerd and Christopher Seiwald at Perforce Software. As a corollary to this item, [http://msmvps.com/blogs/peterritchie/archive/2009/03/11/developing-with-source-code-control-best-practices-part-2.aspx generated code] (object files, executable results of builds, etc.) should '''not''' be stored in the SCM repository.
* '''Create meaningful comments when committing files:''' By writing descriptive comments about a check-in, it will be easier for someone in the future to understand the rationale behind a change.
* '''Branch only when needed:''' The [http://www.perforce.com/perforce/papers/bestpractices.html white paper] mentioned previously speaks most to this point in its section 4, but it is also mentioned in [http://books.google.com/books?id=-2wqcKAq4tIC&pg=PA45&lpg=PA45&dq=source+code+control+best+practices other places]. In particular, when more than one version of a software product is being developed concurrently, especially when the rules for checking out and committing source files may be different between the multiple version, branching is necessary to help the development team manage their project effectively.

=== Links and Resources ===

Review these references for additional information on SCM best practices:
* http://msmvps.com/blogs/peterritchie/archive/2008/10/18/developing-with-source-code-control-best-practices-part-1.aspx
* http://msmvps.com/blogs/peterritchie/archive/2009/03/11/developing-with-source-code-control-best-practices-part-2.aspx
* http://www.perforce.com/perforce/papers/bestpractices.html
* http://msdn.microsoft.com/en-us/library/ee371247%28Expression.30%29.aspx
* http://books.google.com/books?id=-2wqcKAq4tIC&pg=PA45&lpg=PA45&dq=source+code+control+best+practices
* http://www.martinfowler.com/articles/continuousIntegration.html

== Conclusion ==

SCMs provide a valuable tool for helping software developers manage change in a software project. Following some of the recommendations presented, a software development team can gain the most effectiveness from the use of SCMs.

== All References ==

* http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
* http://msmvps.com/blogs/peterritchie/archive/2008/10/18/developing-with-source-code-control-best-practices-part-1.aspx
* http://msmvps.com/blogs/peterritchie/archive/2009/03/11/developing-with-source-code-control-best-practices-part-2.aspx
* http://www.perforce.com/perforce/papers/bestpractices.html
* http://www.ericsink.com/scm/source_control.html
* http://svnbook.red-bean.com/en/1.4/svn-book.html
* http://msdn.microsoft.com/en-us/library/ee371247%28Expression.30%29.aspx
* http://books.google.com/books?id=-2wqcKAq4tIC&pg=PA45&lpg=PA45&dq=source+code+control+best+practices
* http://en.wikipedia.org/wiki/Source_Code_Management
* http://betterexplained.com/articles/a-visual-guide-to-version-control/
* http://www.martinfowler.com/articles/continuousIntegration.html
* [P 05] Pressman, Roger S., Software Engineering: A Practitioner’s Approach, pp. 739-768, McGraw-Hill, New York, NY, 2005
* [HT 00] Hunt A. and Thomas D., The Pragmatic Programmer: From Journeyman to Master, pp. 86-89, Addison-Wesley, Boston, MA, 2000
* [D 90] Dart, S. [http://www.sei.cmu.edu/reports/90tr011.pdf “Spectrum of Functionality in Configuration Management Systems"], Software Engineering Institute, 1990.

CSC/ECE 517 Fall 2009/wiki1a 4 co

2009-09-07T19:14:27Z

Catowner:

== Best Practices For Source-Control Management With Version-Control Systems ==

“Tip 23: '''Always Use Source Code Control'''”
– Hunt and Thomas, The Pragmatic Programmer [HT 00]

In software development, change is almost always inevitable [P 05] . Using a source configuration management (SCM) system (also known as a Source Code Control System (SCCS) or version-control system) can help individuals and teams manage the changes that occur during the software development process [D 90]. This article will provide the reader with basic information, and direct the reader to additional reading for more in-depth consideration.

== Why Source Code Control is Necessary ==

According to Pressman, “Change is inevitable when computer software is built. [P 05]” He suggests four primary reasons for change:
* New business or market conditions
* New customer needs
* Reorganization, business growth, or downsizing
* Budgetary or scheduling constraints
Each of these reasons can cause changes in project requirements, in project priorities, or in the resources available to create or enhance a project. Managing the change with an SCM enables engineers to focus on technical work, and enables project managers to control changes which can affect project outcomes.

=== Links and Resources ===

These links and resources can help the reader further understand the need for source code control:
* http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf, pp. 176-178.
* Dart, S. [http://www.sei.cmu.edu/reports/90tr011.pdf “Spectrum of Functionality in Configuration Management Systems"], Software Engineering Institute, 1990. Review pp. 1-4.
* http://svnbook.red-bean.com/en/1.4/svn-book.html, review the Forward section.
* [http://betterexplained.com/articles/a-visual-guide-to-version-control/ A Visual Guide to Version Control]. Review the section titled “So Why Do We Need A Version Control System (VCS)?”
* Pressman, Roger S., Software Engineering: A Practitioner’s Approach, pp. 739-742, McGraw-Hill, New York, NY, 2005

== Understanding Basic Concepts ==

For the reader new to SCM, there are a few basic terms and concepts that should be understood before best practices are considered:
* '''Check-in''' or '''Commit''' – Writing changes to the source code repository
* [http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.basic.vsn-models.lock-unlock.dia-1 '''Lock-Modify-Unlock Model''']: An SCM model that requires a developer to reserve or lock a source file before making changes to the file. This lock prevents other developers from modifying the file.
* [http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.basic.vsn-models.copy-merge.dia-1 '''Change-Modify-Merge Model''']: An SCM model that allows multiple developers to make changes to a source file. Upon commit, if the source file has been updated by another developer, a merge of the updated file with the developers change is necessary in order to preserve all the updates. Depending on the SCM and the nature of the change, the merge operation may be performed by the SCM or by the developer.
* '''Revision''' – The version identifier of the source file (e.g. v1, v2, v2.1, etc). Each commit of a source file will produce a new revision value.
* '''Baseline''' – The root of a development stream, where changes that are intended to be integrated into the main project will eventually migrate.
* '''Branch''' – An offshoot from the baseline where prototype, testing, or other work can be performed that does not immediately affect the baseline. Eventually, a branch may be merged back into the baseline.

=== Links and Resources ===

These links can provide the reader with additional information on SCM vocabulary:

* [http://msmvps.com/blogs/peterritchie/archive/2009/03/11/developing-with-source-code-control-best-practices-part-2.aspx Developing with Source Code Control - Best Practices Part 2]: Review the '''Vocabulary''' section.
* [http://betterexplained.com/articles/a-visual-guide-to-version-control/ A Visual Guide to Version Control]: Review the '''Learn the Lingo''' section.
* [http://en.wikipedia.org/wiki/Source_Code_Management#Common_vocabulary Revision Control] in Wikipedia. Review the '''Common Vocabulary''' section.

== Advice on Using an SCM or SCCS ==

There is differing advice on using an SCM to manage projects, but there are some consistent messages:

* '''Use a source configuration management product.''': When working on teams, there is a general consensus that an SCM will greatly help the team manage changes. Further, Hunt and Thomas [HT 00] suggest that even an individual should use an SCM to manage their work, even if their team does not, because of its ability to archive work and to "undo" mistakes.
* '''Commit code changes frequently.''': Much of the advice suggests that source code should be [http://www.martinfowler.com/articles/continuousIntegration.html integrated on a regular basis], some even suggesting [http://www.extremeprogramming.org/rules/integrateoften.html checking-in code every few hours].
* '''In a Lock-Modify-Unlock model, check-out only what you need.''': [http://msdn.microsoft.com/en-us/library/ee371247%28Expression.30%29.aspx This advice] is probably obvious, but in the Lock-Modify-Unlock model, source files will be unavailable for others to update in the Lock phase, so keeping that number of files to a minimum reduces programming team "deadlocks". For development teams that have the maturity or tooling, a Change-Modify-Merge model reduces the concern about reserving files, but does not eliminate the potential issues (in particular, dealing with [http://msmvps.com/blogs/peterritchie/archive/2009/03/11/developing-with-source-code-control-best-practices-part-2.aspx merge conflicts]).
* '''Store tooling as well as source code in the SCM.''': Actually, much advice suggests storing [http://books.google.com/books?id=-2wqcKAq4tIC&pg=PA45&lpg=PA45&dq=source+code+control+best+practices even more] artifacts, but in particular, if a software team wants to recreate a specific version of the software, it will likely be crucial to have access to the original tools that created that version, as well as the source code. See section 6 of the white paper [http://www.perforce.com/perforce/papers/bestpractices.html High-level Best Practices in Software Configuration Management] by Laura Wingerd and Christopher Seiwald at Perforce Software.
* '''more''':

=== Links and Resources ===

Review these references for additional information on SCM best practices:
* http://msmvps.com/blogs/peterritchie/archive/2008/10/18/developing-with-source-code-control-best-practices-part-1.aspx
* http://msmvps.com/blogs/peterritchie/archive/2009/03/11/developing-with-source-code-control-best-practices-part-2.aspx
* http://www.perforce.com/perforce/papers/bestpractices.html
* http://msdn.microsoft.com/en-us/library/ee371247%28Expression.30%29.aspx
* http://books.google.com/books?id=-2wqcKAq4tIC&pg=PA45&lpg=PA45&dq=source+code+control+best+practices
* http://www.martinfowler.com/articles/continuousIntegration.html

== Conclusion ==

SCMs provide a valuable tool for helping software developers manage change in a software project. Following some of the recommendations presented, a software development team can gain the most effectiveness from the use of SCMs.

== All References ==

* http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
* http://msmvps.com/blogs/peterritchie/archive/2008/10/18/developing-with-source-code-control-best-practices-part-1.aspx
* http://msmvps.com/blogs/peterritchie/archive/2009/03/11/developing-with-source-code-control-best-practices-part-2.aspx
* http://www.perforce.com/perforce/papers/bestpractices.html
* http://www.ericsink.com/scm/source_control.html
* http://svnbook.red-bean.com/en/1.4/svn-book.html
* http://msdn.microsoft.com/en-us/library/ee371247%28Expression.30%29.aspx
* http://books.google.com/books?id=-2wqcKAq4tIC&pg=PA45&lpg=PA45&dq=source+code+control+best+practices
* http://en.wikipedia.org/wiki/Source_Code_Management
* http://betterexplained.com/articles/a-visual-guide-to-version-control/
* http://www.martinfowler.com/articles/continuousIntegration.html
* [P 05] Pressman, Roger S., Software Engineering: A Practitioner’s Approach, pp. 739-768, McGraw-Hill, New York, NY, 2005
* [HT 00] Hunt A. and Thomas D., The Pragmatic Programmer: From Journeyman to Master, pp. 86-89, Addison-Wesley, Boston, MA, 2000
* [D 90] Dart, S. [http://www.sei.cmu.edu/reports/90tr011.pdf “Spectrum of Functionality in Configuration Management Systems"], Software Engineering Institute, 1990.

CSC/ECE 517 Fall 2009/wiki1a 4 co

2009-09-07T19:09:55Z

Catowner:

== Best Practices For Source-Control Management With Version-Control Systems ==

“Tip 23: '''Always Use Source Code Control'''”
– Hunt and Thomas, The Pragmatic Programmer [HT 00]

In software development, change is almost always inevitable [P 05] . Using a source configuration management (SCM) system (also known as a Source Code Control System (SCCS) or version-control system) can help individuals and teams manage the changes that occur during the software development process [D 90]. This article will provide the reader with basic information, and direct the reader to additional reading for more in-depth consideration.

== Why Source Code Control is Necessary ==

According to Pressman, “Change is inevitable when computer software is built. [P 05]” He suggests four primary reasons for change:
* New business or market conditions
* New customer needs
* Reorganization, business growth, or downsizing
* Budgetary or scheduling constraints
Each of these reasons can cause changes in project requirements, in project priorities, or in the resources available to create or enhance a project. Managing the change with an SCM enables engineers to focus on technical work, and enables project managers to control changes which can affect project outcomes.

=== Links and Resources ===

These links and resources can help the reader further understand the need for source code control:
* http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf, pp. 176-178.
* Dart, S. [http://www.sei.cmu.edu/reports/90tr011.pdf “Spectrum of Functionality in Configuration Management Systems"], Software Engineering Institute, 1990. Review pp. 1-4.
* http://svnbook.red-bean.com/en/1.4/svn-book.html, review the Forward section.
* [http://betterexplained.com/articles/a-visual-guide-to-version-control/ A Visual Guide to Version Control]. Review the section titled “So Why Do We Need A Version Control System (VCS)?”
* Pressman, Roger S., Software Engineering: A Practitioner’s Approach, pp. 739-742, McGraw-Hill, New York, NY, 2005

== Understanding Basic Concepts ==

For the reader new to SCM, there are a few basic terms and concepts that should be understood before best practices are considered:
* '''Check-in''' or '''Commit''' – Writing changes to the source code repository
* [http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.basic.vsn-models.lock-unlock.dia-1 '''Lock-Modify-Unlock Model''']: An SCM model that requires a developer to reserve or lock a source file before making changes to the file. This lock prevents other developers from modifying the file.
* [http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.basic.vsn-models.copy-merge.dia-1 '''Change-Modify-Merge Model''']: An SCM model that allows multiple developers to make changes to a source file. Upon commit, if the source file has been updated by another developer, a merge of the updated file with the developers change is necessary in order to preserve all the updates. Depending on the SCM and the nature of the change, the merge operation may be performed by the SCM or by the developer.
* '''Revision''' – The version identifier of the source file (e.g. v1, v2, v2.1, etc). Each commit of a source file will produce a new revision value.
* '''Baseline''' – The root of a development stream, where changes that are intended to be integrated into the main project will eventually migrate.
* '''Branch''' – An offshoot from the baseline where prototype, testing, or other work can be performed that does not immediately affect the baseline. Eventually, a branch may be merged back into the baseline.

=== Links and Resources ===

These links can provide the reader with additional information on SCM vocabulary:

* [http://msmvps.com/blogs/peterritchie/archive/2009/03/11/developing-with-source-code-control-best-practices-part-2.aspx Developing with Source Code Control - Best Practices Part 2]: Review the '''Vocabulary''' section.
* [http://betterexplained.com/articles/a-visual-guide-to-version-control/ A Visual Guide to Version Control]: Review the '''Learn the Lingo''' section.
* [http://en.wikipedia.org/wiki/Source_Code_Management#Common_vocabulary Revision Control] in Wikipedia. Review the '''Common Vocabulary''' section.

== Advice on Using an SCM or SCCS ==

There is differing advice on using an SCM to manage projects, but there are some consistent messages:

* '''Use a source configuration management product.''': When working on teams, there is a general consensus that an SCM will greatly help the team manage changes. Further, Hunt and Thomas [HT 00] suggest that even an individual should use an SCM to manage their work, even if their team does not, because of its ability to archive work and to "undo" mistakes.
* '''Commit code changes frequently.''': Much of the advice suggests that source code should be [http://www.martinfowler.com/articles/continuousIntegration.html integrated on a regular basis], some even suggesting [http://www.extremeprogramming.org/rules/integrateoften.html checking-in code every few hours].
* '''In a Lock-Modify-Unlock model, check-out only what you need.''': [http://msdn.microsoft.com/en-us/library/ee371247%28Expression.30%29.aspx This advice] is probably obvious, but in the Lock-Modify-Unlock model, source files will be unavailable for others to update in the Lock phase, so keeping that number of files to a minimum reduces programming team "deadlocks". For development teams that have the maturity or tooling, a Change-Modify-Merge model reduces the concern about reserving files, but does not eliminate the potential issues (in particular, dealing with [http://msmvps.com/blogs/peterritchie/archive/2009/03/11/developing-with-source-code-control-best-practices-part-2.aspx merge conflicts]).
* '''Store tooling as well as source code in the SCM.''': Actually, much advice suggests storing [http://books.google.com/books?id=-2wqcKAq4tIC&pg=PA45&lpg=PA45&dq=source+code+control+best+practices even more] artifacts, but in particular, if a software team wants to recreate a specific version of the software, it will likely be crucial to have access to the original tools that created that version, as well as the source code. See section 6 of the white paper [http://www.perforce.com/perforce/papers/bestpractices.html High-level Best Practices in Software Configuration Management] by Laura Wingerd and Christopher Seiwald at Perforce Software.
* '''more''':

=== Links and Resources ===

* http://msmvps.com/blogs/peterritchie/archive/2008/10/18/developing-with-source-code-control-best-practices-part-1.aspx
* http://msmvps.com/blogs/peterritchie/archive/2009/03/11/developing-with-source-code-control-best-practices-part-2.aspx
* http://www.perforce.com/perforce/papers/bestpractices.html
* http://msdn.microsoft.com/en-us/library/ee371247%28Expression.30%29.aspx
* http://books.google.com/books?id=-2wqcKAq4tIC&pg=PA45&lpg=PA45&dq=source+code+control+best+practices
* http://www.martinfowler.com/articles/continuousIntegration.html

== All References ==
* http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
* http://msmvps.com/blogs/peterritchie/archive/2008/10/18/developing-with-source-code-control-best-practices-part-1.aspx
* http://msmvps.com/blogs/peterritchie/archive/2009/03/11/developing-with-source-code-control-best-practices-part-2.aspx
* http://www.perforce.com/perforce/papers/bestpractices.html
* http://www.ericsink.com/scm/source_control.html
* http://svnbook.red-bean.com/en/1.4/svn-book.html
* http://msdn.microsoft.com/en-us/library/ee371247%28Expression.30%29.aspx
* http://books.google.com/books?id=-2wqcKAq4tIC&pg=PA45&lpg=PA45&dq=source+code+control+best+practices
* http://en.wikipedia.org/wiki/Source_Code_Management
* http://betterexplained.com/articles/a-visual-guide-to-version-control/
* http://www.martinfowler.com/articles/continuousIntegration.html
* [P 05] Pressman, Roger S., Software Engineering: A Practitioner’s Approach, pp. 739-768, McGraw-Hill, New York, NY, 2005
* [HT 00] Hunt A. and Thomas D., The Pragmatic Programmer: From Journeyman to Master, pp. 86-89, Addison-Wesley, Boston, MA, 2000
* [D 90] Dart, S. [http://www.sei.cmu.edu/reports/90tr011.pdf “Spectrum of Functionality in Configuration Management Systems"], Software Engineering Institute, 1990.

CSC/ECE 517 Fall 2009/wiki1a 4 co

2009-09-07T19:07:05Z

Catowner:

== Best Practices For Source-Control Management With Version-Control Systems ==

“Tip 23: '''Always Use Source Code Control'''”
– Hunt and Thomas, The Pragmatic Programmer [HT 00]

In software development, change is almost always inevitable [P 05] . Using a source configuration management (SCM) system (also known as a Source Code Control System (SCCS) or version-control system) can help individuals and teams manage the changes that occur during the software development process [D 90]. This article will provide the reader with basic information, and direct the reader to additional reading for more in-depth consideration.

== Why Source Code Control is Necessary ==

According to Pressman, “Change is inevitable when computer software is built. [P 05]” He suggests four primary reasons for change:
* New business or market conditions
* New customer needs
* Reorganization, business growth, or downsizing
* Budgetary or scheduling constraints
Each of these reasons can cause changes in project requirements, in project priorities, or in the resources available to create or enhance a project. Managing the change with an SCM enables engineers to focus on technical work, and enables project managers to control changes which can affect project outcomes.

=== Links and Resources ===

These links and resources can help the reader further understand the need for source code control:
* http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf, pp. 176-178.
* Dart, S. [http://www.sei.cmu.edu/reports/90tr011.pdf “Spectrum of Functionality in Configuration Management Systems"], Software Engineering Institute, 1990. Review pp. 1-4.
* http://svnbook.red-bean.com/en/1.4/svn-book.html, review the Forward section.
* [http://betterexplained.com/articles/a-visual-guide-to-version-control/ A Visual Guide to Version Control]. Review the section titled “So Why Do We Need A Version Control System (VCS)?”
* Pressman, Roger S., Software Engineering: A Practitioner’s Approach, pp. 739-742, McGraw-Hill, New York, NY, 2005

== Understanding Basic Concepts ==

For the reader new to SCM, there are a few basic terms and concepts that should be understood before best practices are considered:
* '''Check-in''' or '''Commit''' – Writing changes to the source code repository
* [http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.basic.vsn-models.lock-unlock.dia-1 '''Lock-Modify-Unlock Model''']: An SCM model that requires a developer to reserve or lock a source file before making changes to the file. This lock prevents other developers from modifying the file.
* [http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.basic.vsn-models.copy-merge.dia-1 '''Change-Modify-Merge Model''']: An SCM model that allows multiple developers to make changes to a source file. Upon commit, if the source file has been updated by another developer, a merge of the updated file with the developers change is necessary in order to preserve all the updates. Depending on the SCM and the nature of the change, the merge operation may be performed by the SCM or by the developer.
* '''Revision''' – The version identifier of the source file (e.g. v1, v2, v2.1, etc). Each commit of a source file will produce a new revision value.
* '''Baseline''' – The root of a development stream, where changes that are intended to be integrated into the main project will eventually migrate.
* '''Branch''' – An offshoot from the baseline where prototype, testing, or other work can be performed that does not immediately affect the baseline. Eventually, a branch may be merged back into the baseline.

=== Links and Resources ===

These links can provide the reader with additional information on SCM vocabulary:

* [http://msmvps.com/blogs/peterritchie/archive/2009/03/11/developing-with-source-code-control-best-practices-part-2.aspx Developing with Source Code Control - Best Practices Part 2]: Review the '''Vocabulary''' section.
* [http://betterexplained.com/articles/a-visual-guide-to-version-control/ A Visual Guide to Version Control]: Review the '''Learn the Lingo''' section.
* [http://en.wikipedia.org/wiki/Source_Code_Management#Common_vocabulary Revision Control] in Wikipedia. Review the '''Common Vocabulary''' section.

== Advice on Using an SCM or SCCS ==

There is differing advice on using an SCM to manage projects, but there are some consistent messages:

* '''Use a source configuration management product.''': When working on teams, there is a general consensus that an SCM will greatly help the team manage changes. Further, Hunt and Thomas [HT 00] suggest that even an individual should use an SCM to manage their work, even if their team does not, because of its ability to archive work and to "undo" mistakes.
* '''Commit code changes frequently.''': Much of the advice suggests that source code should be [http://www.martinfowler.com/articles/continuousIntegration.html integrated on a regular basis], some even suggesting [http://www.extremeprogramming.org/rules/integrateoften.html checking-in code every few hours].
* '''In a Lock-Modify-Unlock model, check-out only what you need.''': [http://msdn.microsoft.com/en-us/library/ee371247%28Expression.30%29.aspx This advice] is probably obvious, but in the Lock-Modify-Unlock model, source files will be unavailable for others to update in the Lock phase, so keeping that number of files to a minimum reduces programming team "deadlocks". For development teams that have the maturity or tooling, a Change-Modify-Merge model reduces the concern about reserving files, but does not eliminate the potential issues (in particular, dealing with [http://msmvps.com/blogs/peterritchie/archive/2009/03/11/developing-with-source-code-control-best-practices-part-2.aspx merge conflicts]).
* '''Store tooling as well as source code in the SCM.''': Actually, much advice suggests storing [http://books.google.com/books?id=-2wqcKAq4tIC&pg=PA45&lpg=PA45&dq=source+code+control+best+practices even more] artifacts, but in particular, if a software team wants to recreate a specific version of the software, it will likely be crucial to have access to the original tools that created that version, as well as the source code. See section 6 of the white paper [http://www.perforce.com/perforce/papers/bestpractices.html High-level Best Practices in Software Configuration Management] by Laura Wingerd and Christopher Seiwald at Perforce Software.
* '''more''':

=== Links and Resources ===

Blah

== References ==
* http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
* http://msmvps.com/blogs/peterritchie/archive/2008/10/18/developing-with-source-code-control-best-practices-part-1.aspx
* http://msmvps.com/blogs/peterritchie/archive/2009/03/11/developing-with-source-code-control-best-practices-part-2.aspx
* http://www.perforce.com/perforce/papers/bestpractices.html
* http://www.ericsink.com/scm/source_control.html
* http://svnbook.red-bean.com/en/1.4/svn-book.html
* http://msdn.microsoft.com/en-us/library/ee371247%28Expression.30%29.aspx
* http://books.google.com/books?id=-2wqcKAq4tIC&pg=PA45&lpg=PA45&dq=source+code+control+best+practices
* http://en.wikipedia.org/wiki/Source_Code_Management
* http://betterexplained.com/articles/a-visual-guide-to-version-control/
* http://www.martinfowler.com/articles/continuousIntegration.html

=== Additional References ===
* [P 05] Pressman, Roger S., Software Engineering: A Practitioner’s Approach, pp. 739-768, McGraw-Hill, New York, NY, 2005
* [HT 00] Hunt A. and Thomas D., The Pragmatic Programmer: From Journeyman to Master, pp. 86-89, Addison-Wesley, Boston, MA, 2000
* [D 90] Dart, S. “Spectrum of Functionality in Configuration Management Systems, Software Engineering Institute, 1990, available at http://www.sei.cmu.edu/reports/90tr011.pdf.

CSC/ECE 517 Fall 2009/wiki1a 4 co

2009-09-07T18:27:29Z

Catowner: /* Links and Resources */

CSC/ECE 517 Fall 2009/wiki1a 4 co

2009-09-07T15:39:19Z

Catowner:

CSC/ECE 517 Fall 2009/wiki1a 4 co

2009-09-07T15:28:15Z

Catowner:

CSC/ECE 517 Fall 2009/wiki1a 4 co

2009-09-07T14:20:35Z

Catowner:

CSC/ECE 517 Fall 2009/wiki1a 4 co

2009-09-07T14:19:56Z

Catowner:

CSC/ECE 517 Fall 2009/wiki1a 4 co

2009-09-07T14:15:03Z

Catowner:

CSC/ECE 517 Fall 2009/wiki1a 4 co

2009-09-07T14:14:33Z

Catowner:

CSC/ECE 517 Fall 2009/wiki1a 4 co

2009-09-07T14:10:10Z

Catowner:

CSC/ECE 517 Fall 2009/wiki1a 4 co

2009-09-07T14:08:52Z

Catowner:

== Best practices for source-control management with version-control systems ==

“Tip 23: Always Use Source Code Control”
– Hunt and Thomas, The Pragmatic Programmer [HT 00]

In software development, change is almost always inevitable [P 05] . Using a source configuration management (SCM) system (also known as a Source Code Control System (SCCS) or version-control system) can help individuals and teams manage the changes that occur during the software development process [D 90]. This article will provide the reader with basic information, and direct the reader to additional reading for more in-depth consideration.

== Why Source Code Control is Necessary ==

According to Pressman, “Change is inevitable when computer software is built. [P 05]” He suggests four primary reasons for change:
* New business or market conditions
* New customer needs
* Reorganization, business growth, or downsizing
* Budgetary or scheduling constraints
Each of these reasons can cause changes in project requirements, in project priorities, or in the resources available to create or enhance a project. Managing the change with an SCM enables engineers to focus on technical work, and enables project managers to control changes which can affect project outcomes.