CSC/ECE 517 Summer 2008/wiki2 5 mo: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 39: Line 39:


The main reason not to repeat yourself in system design and coding is for
The main reason not to repeat yourself in system design and coding is for
software maintenence.  If a change is needed in a function and that function
software maintenance.  If a change is needed in a function and that function
was copied across several different classes or functional areas of the
was copied across several different classes or functional areas of the
system, then it needs to be fixed in every location.  Because of Murphy's Law  
system, then it needs to be fixed in every location.  Because of Murphy's Law  
you are guaranteed to miss that least one of the updates.  According to Dave  
you are guaranteed to miss that least one of the updates.  According to Dave  
Thomas, the code enters maintenance mode after the first
Thomas, the code enters maintenance mode after the first submission of the code to
the project library. 
 
== Programmer Checklist ==
 
1. Make sure the system design has abstracted out similar functionality to a
higher level in the system design.
 
2. When designing the objects make sure the objects that need similar tasks,
are designed in parallel so that they can have the code for both in one place.
 
3. At the code level, constants need to be used to specify strings or numbers
that are used in more than one place

Revision as of 21:15, 26 June 2008

The DRY Principle

'Don't Repeat Yourself', DRY, is a software engineering principle that encourages the reduction of duplication in software. According to Dave Thomas, the pragmatic programmer, "DRY says that every piece of system knowledge should have one authoritative, unambiguous representation". [1] This is a very strong requirement. It includes duplication at the highest levels of program requirements and design.

One Authoritative, Unambiguous Representation

What does this really mean? At the highest level, the system architecture needs to have global definitions areas for functions that cross different functional design boundaries. A classic example of a system breakdown due to duplication in system requirements, is that of the Mars Climate Orbiter [2]. The space vehicle malfunctioned do to a system architecture failure. Two different parts of the system were working with two different measurement systems, one in metric units and the other in imperial units. Something as important as system measurements should have been abstracted out to a system wide area in the architecture of the software. It should have been specified in only one area of the system requirements, but it obviously was specified in both parts of the system.

At intermediate levels, if different objects need very similar functions, the code should not be duplicated in the classes. One option is to have the two classes inherit from a parent that has the function coded there. This is not always an available option because many OO languages do not support multiple inheritance. With Java, you have interfaces, but they don't really help that much. You still need to code the method in more than one place. With Ruby mixins this is not an issue. Just code a Module with that function defined and mix it in with both classes.

With user interfaces, specifications of screen sizes. margins in Web pages and the like should be made with global constants. Ruby on Rails uses partial forms that let more that on HTML pages reuse parts of the form that are needed for more than one screen.

Why not?

The main reason not to repeat yourself in system design and coding is for software maintenance. If a change is needed in a function and that function was copied across several different classes or functional areas of the system, then it needs to be fixed in every location. Because of Murphy's Law you are guaranteed to miss that least one of the updates. According to Dave Thomas, the code enters maintenance mode after the first submission of the code to the project library.

Programmer Checklist

1. Make sure the system design has abstracted out similar functionality to a higher level in the system design.

2. When designing the objects make sure the objects that need similar tasks, are designed in parallel so that they can have the code for both in one place.

3. At the code level, constants need to be used to specify strings or numbers that are used in more than one place