One of the most famous principles in software development, DRY (Don’t repeat yourself) states that “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”. This is a very good principle and it helps developers to write better code by abstracting out codes that are common and write them in a single location. What brings me to write this article is that developers take this as a rule of thumb and mistakenly joins common codes when they should not. In this article, I’m going to demonstrate when it’s not the case to apply the DRY principle.
I was working some years ago in a car dealership retail company that used to have more than a hundred stores. There were two types of stores, the ones that sell new cars and have a garage for repairing and maintenance and the ones that only sell used cars and don’t have a garage.
There was a table in the main database that stores some information about the garage if the store has a garage.
One day we needed to get a list of the stores that sell used cars only. The first thing a developer has suggested was to query that table because if the store exists in that table it sells new cars and if it does not exist it only sells used cars.
The developer argued that having another table to store this information would be duplication.
Ok, let’s go a little further. What if the company decided to have a garage in used cars stores? What if the company decided that one of the new cars stores wouldn’t have a garage anymore because there is another store, with a garage, very close to it, therefore there’s no need to have a garage?
Do you see? the main point here is: If two things change for different reasons there is no duplication, even if they seem pretty similar on first thought.
I will give you another example.
You come across with this code:
You find it terrible and decide to create an abstraction for Approvals. Then, create an Interface IApprovable. Your code goes like this:
Everything seems to be perfect now. Except for the fact that business always changes and now, for customers, we have to add two more days on ApprovedDate.
“It’s easy”, you think, “it’s just an IF”.
Then, another requirement comes from business analysts and you have to adapt your code again and again.
Of course, this code could be much more flexible and smart, it’s just an example though. What I tried to show is that sometimes when you remove a duplication, you are adding a possible premature optimization (reference from Knuth, Donald paper “Structured Programming with go to Statements”) and abstracting things that you may have to separate again in the future.
In conclusion, I’m not saying the DRY principle is wrong, of course it is not. However, I’m trying to show the importance of being critical when you face something that seems to be duplicated.
The first principle of SOLID, single responsibility principle (SRP), also can be quite confusing for a similar reason, that’s subject for another post though.
Denis Capeto 