CSC/ECE 517 Fall 2009/wiki3 4 ashi4: Difference between revisions
Line 51: | Line 51: | ||
Let us look into DRY | Let us look into DRY | ||
[[Image:dry. | [[Image:dry.jpg|thumb|center|550px|alt=Taken from http://tagschema.com/blogs/tagschema/ |Taken from http://tagschema.com/blogs/tagschema/ ]] | ||
== When Data Duplication wins over DRY... == | == When Data Duplication wins over DRY... == |
Revision as of 01:25, 19 November 2009
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.
Some Basic Terminologies
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.
Why Data Duplication is harmful
The previous section has discussed Data Duplication can be a big problem in 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
Let us look into DRY
![Taken from http://tagschema.com/blogs/tagschema/](/images/a/ad/Dry.jpg)
When Data Duplication wins over DRY...
Data Duplication while bad as discussed in the previous section, it is 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 have to get data or instruction from the main memory.
Buffer Manager in DBMS is an intermediate layer in the DBMS which gets the DB pages from the Disk and buffers them for the upper layer components to use. Buffer Manager creates copies of the DB pages and stores in the buffer pool.
Source Control software creates a copy of the source files for each project to ensure that the properly working source are not disturbed.
Read-copy-update (RCU) [5] is an operating system kernel technology for improving performance on computers with more than one CPU. RCU allows you to read a shared data structure as if there were 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, after which the old copy can be deleted.
Global Data in system can be a cause of concern because multiple components of the system share the same data specially in a multi-threaded application. Instead, we could have multiple copies of the data accessible locally to each component.
Prototypes are another example where DRY is violated. When a new object has to be created, we clone the prototype there by creating multiple copies of the same thing in the system.
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.
Conclusion
DRY is one of the important principle that need to be used while design a system. Following
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