CSC/ECE 517 Fall 2009/wiki3 4 br
- This document could benefit from additional links and references that can allow the reader to go beyond the wiki material.
- I think the topic is fairly well covered, although you could provide some additional details on where else the DRY principle applies, like with certain design patterns.
- Organization could have been better.
- Coverage could have been more on the decision about when to use the principle and the desirable features of the principle.
- More examples could have been provided.
Don't Repeat Yourself - Introduction
DRY (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.
DRY principle - Code
The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one way to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]
- Example: Repeated Code
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}
- Example: DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}
The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.
DRY principle - Data
Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed, and in general, data should not be duplicated for the following reasons:
* Additional memory - data duplication usually means more memory to store and manipulate * Out-of-date Data - data duplication usually means that you need to keep the same data in multiple locations in sync
Scenarios where DRY principle is violated
There are certain scenarios, however, where duplication might not only be acceptable, but at times desirable. However, in order to avoid the reasons just mentioned, certain rules should be followed.
Source Version Control
Source version control is a management control tool that tracks different versions of data. It is usually used in software development teams where several people might be making change to the same file. It allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production
This is direct violation of the DRY principle since at any given time, there could be copies of the same file in different branches, allowing developers to work concurrently in different areas of the code without affection one another.
Caching
Caching of data is the duplication of data that has been retrieved from a certain location, or calculated at an earlier time. It is used when the time or processing power would be expensive to retrieve/calculate the data again. Caching has proved to be useful in numerous applications including caching large amount of data transferred on the network, or caching data inside the processors that have been retrieved from memory.
This violates the DRY principle by copying data locally in order to achieve faster processing than would normally be possible by having to fetch the same data across the network or another slower location.
Documentation
Documentation can be automatically pulled and generated from code, which would essentially duplicate code and comments to create the document. This is a useful technique since an updated documentation can be directly retrieved and created from the modified code without requiring individual to manually modify the doc. This actually ensures that the document is up-to-date based on the latest code.
This example of violation of the DRY Principle allows the developers to spent less time updating documentation every time the code is changed by allowing the documentation to be directly retrieved from the source code. This is in direct violation of the DRY principle as the same data/code now appears in two different locations.
How to determine when to duplicate data
When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3] The duplication of data should only be considered when it will save time or resources or both. Furthermore, the authoritative source of the data is well known.
Conclusion
Ideally, code and data should not be duplicated making maintainability and synchronization of information easy. However, this document has described several scenarios where violating the DRY principle with regards to the duplication of data is acceptable. In all examples provided, duplicating data significantly saved network bandwidth, computing processing, or human time. Also, in all of the examples, only a single source of data was the authoritative source.
References
1. http://en.wikipedia.org/wiki/DRY
2. Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II
3. http://c2.com/cgi/wiki?DontRepeatYourself