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

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
 
Line 1: Line 1:
== The DRY Principle ==
== 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.
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.  Twp 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.

Revision as of 20:22, 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.

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. Twp 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.