Every piece of Knowledge must have a single, unambiguous, authoritative representation within a system
From time to time it becomes easy to lower your standard and take a shortcut here and there. For developer that often times means duplicating code instead of encapsulating it in a separate class or even a function. Of course, there are times when small duplication can be completely justified and will not harm the entire code base. But, in my opinion, most of the cases can be refactored to look much better than that. Wherever possible it is good to strive for singling functionality and certain pieces of code out.
There are several reasons why you would want to consider to not repeat yourself.
- Future Modification
- Debugging
- Team Work
You will be very likely to come back with the desire to introduce new functionality or modify existing one. And that’s when you would really want to make sure that code is organized in a way that similar parts do not repeat themselves. Because if they do repeat themselves, in worst case, you will need to go over the entire code base to find same piece of code and change it. Whereas, if you have put all related code in one place, you will know where to look for, and will also know that changes in this module will be applied everywhere.
You would also want to keep it DRY because just like in the example above you want to keep a particular functionality uniform code-wise. What I mean by that is the code for a particular function should be the same throughout your project. For example, if you want to implement error printing function, it should be the exact same implementation as anywhere else. What would happen if it is not? You would introduce bugs and errors, which in some cases might be difficult to identify.
Most developers work in teams. And as a team player it is important to make sure that you make your team’s life easier, not more difficult. One more way you could do that is by writing DRY code. Whenever working on a project, one day you will be writing a function that checks if the user is authenticated, and the other day another developer will take over that part to implement some modifications. If you didn’t implement authentication function as a singular block of code, your teammate might find it troublesome to look everywhere for that functionality.
There are several ways to encapsulate your code and reuse it throughout your project.
- If you realize that particular functionality will be needed in many places of your project, and if it would contain more than one function, consider encapsulating it in a separate class. For example, the authentication mechanism is usually best implemented as a separate class, and then referenced to throughout application. On top of that you can also consider using a design pattern with it, like singleton or chain of responsibility.
- If the repeating block seem to have a small scope of responsibility, you can consider separating it into a function within the class that you are working. If you will need this function in other classes too, consider putting it into a helper, utility, or a service class.
- Lastly, make sure that you are familiar with the language or API that you are using well enough. Another type of duplication that can occur, is the duplication of existing functions within the API. Don’t reinvent the wheel. There are already great implementations of even really specific features. RTFM!
Making sure that the code stays DRY wont come really easy and quick. Instead it is usually something that comes with experience. Be mindful of it, and you will start to see more and more situations where code can be improved that way.
Abstrakt Kode 