CSC/ECE 517 Fall 2009/wiki3 4 br

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

the 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

Caching

• 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

• 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