A simple design principle

This week blog will be talking about DRY design principle and it will be based on this article. These principles are really useful for software development yet there are still quite a lot of people tripping over it.

A bit background about DRY. DRY stands for Don't Repeat Yourself. It is really simple but important to understand. It is essentially know as a philosophy that packages the logic into representation. This design principle has been known for a long time and its acronym is mentioned in the book The Pragmatic Programmer, which is published in 1999. The concept of DRY wouldn't be a big of a deal when you are writing a small program, a code snippet or a short script. However, when it comes to a big software project, not applying this principle would not only cause a lot of problems but also can waste resources and increase the length and complexity to your programs, and all of these would lead to the increasing requirement of your clients' machine. Besides, it is not just bad for the hardware itself, it would take more time for you and other developers to just understand your code.

To achieving DRYness, a simple way to put it is to divide your system into components, where each of these components represents its own subsystem's functionality. For instance, if you are building a file sharing system, your program should break down into multiple pieces like git system, file management system, etc. and inside user management system, there can be subcomponents like role management system and access control system. As the program is divided further, there would be a clear hierarchy where each subcomponent would only have one function to support the components themselves, and it would greatly reduce the complexity.

I really like the part where the author quotes that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system" meaning that if you are repeating any piece of information, you are doing it wrong. This can be really easy to make mistake and I actually did quite a lot when I first started programming. For example, instead of making the connection to the database every time you need it and then close it immediately after you are done with it, you should make a separate class that handles the connection to the database as a singleton and it should open the connection to the database when the first time you call the function and close it when a specific event is triggered. In a perfect implementation, every piece of information should be encapsulated its knowledge in the form of variables, objects or a class property.

It is absolutely impossible to achieve 100% DRY, but the more DRY your code is, the better for you and other developers to maintain it. It is a concept that is worth looking into while revising your code whether it is a small or large project to develop a good habit of doing it.


Popular posts from this blog

Software Quality Assurance Introduction

Reflect as you work

Static testing and Dynamic testing