Reframing the DRY principle as DRUM

As a fledgling programmer you’re bombarded by commandments telling you what’s considered right programming and wrong programming. These edicts can seem very useful and on the surface seem irrefutable. But if they are applied without deeper thought they can do more harm than good. One of the worst offenders is ‘thy code shalt have abundant comments’. Another questionable one is the DRY principle.

‘DRY’ is an acronym meaning: Don’t Repeat Yourself. It is often interpreted to mean there should be no similar blocks of code in a codebase. And certainly no copy-pasted code. But in my opinion this interpretation is too broad. I’d like to propose a new acronym: ‘DRUM’ (Don’t Repeat Universal Meaning).

Take the following example:

Example of ‘repeated’ (similar) code

Our business domain has two commands:

In the code above, these two commands have a handler. This handling code is run whenever a command is executed. The code is very similar. In each handler the following happens:

The only difference is the template that’s used when generating a PDF.

If we were thinking in a ‘DRY’ way, we’d dutifully set about removing the repeated code:

Example of an attempt to remove all ‘repeated’ (similar) code

What we’ve done here is:

By doing this we have successfully not repeated ourselves.

But it has drawbacks. If the way in which our system handles one of these commands changes (for example if the account statement needs to become a CSV instead of a PDF) our situation would be:

These issues have all arisen because in the original example we were mostly only superficially repeating ourselves — which is not a problem at all. The code looked similar only because we happen to be producing an account statement and a payment overdue notice in a similar way. But these two things are not the same. They are two independent concepts and it’s a mistake to couple them.

If we now approach the original code in terms of ‘DRUM’ (Don’t Repeat Universal Meaning) we can craft the following:

Example of ‘repeated’ (similar) code but no repeated implementations of meaning

We now have two non-coupled handlers for managing the two very separate domain commands. If the way in which our system produces the output of one of these commands changes: we’ll be able to easily adapt to that change without concern for the other command handler. This negates the drawbacks listed above.

However, you’ll notice that there was one aspect of the code that was not repeated. This was the way in which the account total was calculated. This is because it’s a piece of universal meaning (and we Don’t Repeat Universal Meaning). The way in which we avoided repeating the universal meaning was to abstract that functionality away. In the case above we have used the SOLID principles of OOP to inject that functionality as a dependent class. But the principle could be applied to other programming paradigms like functional programming.

The take-aways of this article are:



Software engineer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store