Or how to watch more cat videos during work
Introduction
Duplication may be the root of all evil in software.
Robert C. Martin
Here, DRY is actually an acronyme and stands for Don’t Repeat Yourself. The absolute basic meaning is that duplicate code is wasted code. This is true for a line of code that gets repeated 2 times throughout your application and also true for big classes that basically do the same and differ in just tiny bits.
The Problem with this problem
Every single line of code might be a future point of maintenance or represent a bug. If this buggy line of code happens to be repeated several times throughout your code make sure to take your weekend off to fix that. Coding by the DRY principle will save you hours of time! Let me first give you a quick example.
Imagine you are supposed to implement a table consisting of 6 equally broad columns. Easy peasy, you think and start of with the first column and set the width using filenameColumn.setColumnWidth(“150px”);
The exact same thing goes for the other columns and you end up with
[pastacode lang=”java” manual=”private%20void%20setColumnWidths()%20%7B%0A%20%20%20%20filenameColumn.setColumnWidth(%22150px%22)%3B%0A%20%20%20%20dateColumn.setColumnWidth(%22150px%22)%3B%0A%20%20%20%20sourceDirectoryColumn.setColumnWidth(%22150px%22)%3B%0A%20%20%20%20destinationDirectoryColumn.setColumnWidth(%22150px%22)%3B%0A%20%20%20%20statusColumn.setColumnWidth(%22150px%22)%3B%0A%20%20%20%20progressColumn.setColumnWidth(%22150px%22)%3B%0A%7D” message=”” highlight=”” provider=”manual”/]
You compile the code, head over to your boss and proudly present him your table. The second he sees it, he screams to your face “TO BROAD!” So you head back to your desk, set the parameter to 100px for all columns. Head to your boss, show him the table, get shouted at “TO NARROW!”, head back, reset all parameters, and continue to change all 6 lines of code every single time until you receive a smile. See the problem here? You always have to change 6 lines of code to basically make the same change.
Now let us consider the following, basically the same, piece of code
[pastacode lang=”java” manual=”private%20void%20setColumnWidths()%20%7B%0A%20%20%20%20String%20columnWidth%20%3D%20%22150px%22%3B%0A%0A%20%20%20%20filenameColumn.setColumnWidth(columnWidth)%3B%0A%20%20%20%20dateColumn.setColumnWidth(columnWidth)%3B%0A%20%20%20%20sourceDirectoryColumn.setColumnWidth(columnWidth)%3B%0A%20%20%20%20destinationDirectoryColumn.setColumnWidth(columnWidth)%3B%0A%20%20%20%20statusColumn.setColumnWidth(columnWidth)%3B%0A%20%20%20%20progressColumn.setColumnWidth(columnWidth)%3B%0A%7D” message=”” highlight=”” provider=”manual”/]
Now we only have to change one line of code affecting all 6 columns. Which one do you prefer?
(Hint: rhetorical question!)
Refactoring baby
The application of the DRY principle is pretty simple. Just do it. I mean, don’t do it. Well, you get the point. The way to identify where to use the it is pretty simple. Every time you feel the itch in your fingers to copy and paste hold still and think about DRY. I do not mean that you should type in your variable names every time, but as soon as you might want to copy the whole line, this is a good indicator that this line would probably be better of in it’s own method, constant or abstract class. You basically take everything that get’s repeated and put it in one single place.
There are a couple of ways on how to apply the DRY principle
- Put repetition in single methods and/or classes
Let us assume you are writing the GUI for an application and are supposed to write some sort of validation. An easy example would be a login window which applies a red border to the textboxes if the entered credentials are wrong. Now let us imagine you have exactly 59 textboxes within 36 classes and every single one has some sort of validation process which, in the end, paints the border red if the entered value is wrong. You ship your product to your customer and he now decides that the red validation border is to dark and he wants it a little brigther. After you received his ask I can see you start crying because you have to open all 36 classes and find all 59 places where the border is painted red. Can you imagine a scenario wich is more prone to bugs? Let’s apply the DRY principle to this horrifying situation. Why not have one single method called setBorderOnError(Textbox textbox) in one single class named TextboxValidator. Again, we only have to change one single line to take effect on all textboxes. No matter how many there are. - Use constants
If you have single arguments that get repeated several times throughout many classes or even throughout methods you should use constants. A good example would be the String columnWidth = “150px” line in my above example. Consider having 6 classes, each one describing one column and every one with it’s own setColumnWidth() method. How can you avoid to change 6 methods in 6 classes if you have to make a alteration? By using constants.
Personally I like to have all my constants in one or two classes. This has two major advantages
- If I hand over my code to one of my coworkers he does not have to search where he can change constants. He knows that he can find them in the constants class.
- Assuming in a later stage of development your client wants to change the constants by himself. Now you are supposed to store all your constants in a text file. Coming this case you only have to modify one single class and not go through several ones and turn your code into a mess.
- Abstraction
A very common situation known by every single developer is a repetition in logic. This might be in the form of huge if-else or switch-case blocks that handle different system behaviour depending on system states. Or many classes that basically describe the same object like a normal user, a premium user and an administrator that contain several lines of repeated variables like eMail address, username and password. Every single one of these repetitions can be addressed by making use of abstraction. I will not get into detail here because we will dive deeper into this in upcoming articles.
What have we learned?
Duplicate code is the devil! Code containing duplication takes tremendously more effort to maintain and is way more prone to bugs. The time spend to maintain your code vastly increases by every single repetition because you not only have to take more time finding one bug, but fixing the same bug on several places in your code.
Avoid duplicate code, spend more time watching cat videos.