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

• Example: DRY

 class Person
   attr_accessor :name
 end

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.