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.
   An Example :

Suppose that we need to develop a software which queries the database very often. If the query is a static query, that is, the 
values given as an input to the query does not change and returns the same result set irrespective of the number of times it is 
executed, it is always a good practice to execute the query once and store the result set which can be used by different parts of 
the source code. This saves us the execution time as well as the memory.

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

The responsibility of a software developer or a software firm does not end with building the software. Neither can the user of the 
software be expected to stay satisfied with the product that has been delivered. Changes or an upgrade might be necessary at any 
time. So imagine, if the code is full of duplication and redundancy, it is almost impossible to understand it and extending 
it.

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.
   An Example :

Documenting the code is completely the programmer's discretion. Suppose there is a variable X which represents a person's salary. 
The salary is computed within a code and stored in X. Every method that uses X needs to have a comment mentioning that X 
represents salary. It would have been a lot easier if the variable name was 'salary'.

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

Suppose there is a method M which calculates salary. For a programmer's convenience, consider that this method is duplicated in a 
different class. Assume that the salary has to be revised for some set of employees, and the programmer changes M in one class but 
misses to do so in another. It would take a lot of effort and time from the person debugging the code to find out why the salary 
is not getting revised in peculiar cases. 

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

The example given in the point 4 explained above is a proof for the reason that we should have just one method M that calculates 
the salary.

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