CSC/ECE 517 Summer 2008/wiki2 5 mo: Difference between revisions
Maryorazem (talk | contribs) |
Maryorazem (talk | contribs) |
||
| Line 8: | Line 8: | ||
highest levels of program requirements and design. | highest levels of program requirements and design. | ||
A classic example of a system breakdown due to duplication in system | What does this really mean? At the highest level, the system architecture | ||
requirements, is that of the Mars Climate Orbiter [2]. The space vehicle | needs to have global definitions areas for functions that cross different | ||
malfunctioned do to a system architecture failure. | functional design boundaries. A classic example of a system breakdown due to | ||
of the system were working with two different measurement systems, one | duplication in system requirements, is that of the Mars Climate Orbiter [2]. | ||
in metric units and the other in imperial units. Something as important | The space vehicle malfunctioned do to a system architecture failure. Two | ||
as system measurements should have been abstracted out to a system wide | different parts of the system were working with two different measurement | ||
area in the architecture of the software. It should have been specified | 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 only one area of the system requirements, but it obviously was specified | ||
in both parts of the system. | in both parts of the system. | ||
At intermediate levels, if different objects need very similar functions, | |||
the code should not be duplicated in in class. 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. | |||
Revision as of 20:39, 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.
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 in class. 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.