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.

An overview of the concepts

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 system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) do 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 the same code (or functionality) somewhere else unmodified.

Don't Repeat Yourself

File:DRY.jpg

DRY principle - related to code

The idea 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: Java classes repeat functionality

 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: Java classes with repeated functionality factored out

 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 other 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 - related to data

The DRY principle not only applies to methods and functions, but also to data.

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.

4.

5.

6.

7.

8.

9.