CSC/ECE 517 Fall 2009/wiki3 4 ashi4

DRY Principle for Data

---

Introduction

Donot Repeat Yourself (DRY) also known as Duplication Is Evil (DIE) is one of the most fundamental principles of programming, or rather we can say that it is the most important principle of good programming. This principle was formulated by Andrew Hunt and David Thomas in their book The Pragmatic Programmer. The principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.". This principle has been broadly accepted and acknowledged by the developers across the globe. It is considered to be one of the best coding practices to build an efficient and flexible code which is not only easy to understand but easy to maintain too. A parallel concept to DRY is Orthogonality which is making the components of the system as functionally independent as possible. It is well understood and an accepted fact that the DRY and the Orthogonality principle together lead to a very well structured code as discussed here. But if we observe the DRY principle more carefully, it is easy to notice that DRY is not only applicable to code but it is applicable to any piece of knowledge that can be represented in some way; one such form of knowledge representation is data. In fact, data and knowledge are used more or less interchangeably. The purpose of this document is to emphasize on the fact that the DRY principle is not only applicable to the code but to the data as well.

Why DRY?

The question should be Why not DRY. When it comes to building or extending a software system, it feels extremely easy to just put in the logic in terms of code and make sure that the code works and the overall system functions properly. However, it is most convenient to not bother whether or not the code follows the best practices or is it easy to maintain. But it is cosidered to be a really good technique to apply the DRY principle here for various reasons;

1. Duplicating the code for convenience causes a lot of overhead in terms of time and space.

2. The system might function really well but it becomes extremely difficult to maintain it since the source code has turned clumsy.

3. It is said that the best way to check whether the code really follows the best practices is to realise whether or not the code needs extensive documentation.

4. It becomes very difficult to debug the code in case of anomalies.

5. It is always a good practice to have one reference.

When Data Duplication wins over DRY...

Data Duplication can be a big problem is many systems. Some of the problems are listed below

• Stale Data: The main problem with having multiple copies of the data is that of stale data present in one of the copies, because it was not updated. This can lead to an undefined system behavior.

• More Memory: Stories multiple copies increases the amount of memory required for the system

Data Duplication while bad, are some times required. Some of the examples are listed below

Caches in Computers basically maintain a copy of data which is present in the main memory. This is good for the system on  
the whole because it increases the overall performance of the computer by making sure that the processor doesn't to get data or 
instruction.

Buffer Manager in DBMS is a intermediate layer in the  DBMS which gets the DB pages from the Disk and buffer them 
for upper layer components to use. 

Source Control software creates creates a copy of the code each member of the teamwhen a more than one person is working a 
project This ensures smother development.

Read-copy-update (RCU)[3] is an operating system kernel technology for improving performance on computers with more than one 
CPU. More technically it is a synchronization mechanism which can sometimes be used as an alternative to a readers-writer lock. 
RCU allows you to read a shared data structure as if there is no other CPU accessing it. When you need to update the data  
structure, you can update the global pointer to the data and keep the old copy until all the threads currently executing inside 
the kernel have completed. The updated pointer ensures that none of the CPUs have any remaining references, so the old copy can be 
deleted. 

Documentation of a code can be a repetition of what the code does. In cases where the code is too simple to be explained, we 
can omit the comments on the basis of DRY, but for the codes which are not only large but clumsy, documentation has to be at every 
possible place even if it means repeating the same thing.

References

1. Andrew Hunt and David Thomas, "Pragmatic Programmer : From Journeyman to Master", Addison-Weasley Publications, October-99.

2. A discussion with the Authors of the Pragmatic Programmer

3. A good introduction to DRY

4. Importance of DRY

5. / Read-Copy-Update