CSC/ECE 517 Fall 2009/wiki3 4 br

Topic: DRY principle for data Most of the literature on the DRY principle relates to code. But the principle also applies to data. Survey the issues related to copying the same data, and give reasons (e.g., caching) why it might sometimes be desirable, and how one should decide where it is helpful not to follow this general rule.

Don't Repeat Yourself

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 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. In general, data, just like code, 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

Data duplication - acceptable?

In some instances, the duplication of data might actually be acceptable and even desirable.

• Source version control 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
• Caching of data can also prove to be useful if directly obtaining the data each time is resource and time intensive. Caching data would result in better system efficiency as long as the authoritative source is well known.
• Documentation can be automatically generated from code, which would essentially duplicate code and comments to create the document.

Data duplication - when is it useful?

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]

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