While trying to learn coding in Java and it's principles, I came across a problem with the DRY principle. From what I know, following a principle is not mandatory but if you should for many reasons.

While coding a program, I ended up with a bunch of methods and a button and a JtextField. When you press the button it gets app, takes the text from the jTextField and process it through the methods and shows the result.

Let's say that I want to create another button that does all the above except the part were the app gets the text from the text field. For example it will get the data from a database.

Should I just copy-paste all the code from the first ActionEvent to the new button or would that violate the DRY Principle? How should I approach this dilemma?

Although the two questions have similarities, I do not want to focus on the reusability but on how to make my code easier to maintain and cleaner.


Copying and pasting code is the opposite of "Don't Repeat Yourself" (DRY). Since I've inherited a lot of legacy code to make better over the years, my chief complaint is the amount of copy/paste code I run into.

The problem DRY solves

You have a part of your application that is re-used in multiple locations in the application. Each time that part is reused, the person who did it simply copied and pasted code. It worked, so in their mind they were done.

Now the customer comes to you and says they need to part to work differently. They only tell you the one page they are working on:

  • If you don't know all the places that the code was copied, you will miss something. I like to think I'm pretty thorough, but I've missed something more often than not.
  • If the software has been in use a long time, the copies will be modified slightly differently, making it harder to maintain

If the original implementer had the same class or method to make all the places use the same code, then there is only one place to fix.

You can go too far

It's really great to have one place to change behavior across your application, but there are times where it is not what you want. Even this requires some time to figure out for yourself. For that side, I would look at Robert Harvey's answer.

The number one sign you've gone too far?

  • You spend so much time figuring out how to repeat yourself that you miss deadlines.

Bottom line

DRY principle helps you write code that is easier to maintain. When you combine it with the Single Responsibility Principle (SRP), you really start to see some benefits. Use the principle as much as you can. When you choose against either DRY or SRP, it is an intentional choice with a reason you can defend.


Here's the dirty little secret of DRY.

If you DRY everything up, and you then change the way the dried up code works, it has a cascading effect on all of those areas you dried up. DRY code creates "one ring to rule them all." Change that ring and you change everything that the ring touches.

There are reasons why you might not want that.

If you're building a modular application where each module has its own responsibility and its own behavior, sometimes you want the confidence that, if you make a change to some code in a given module, that there's no possibility of your code change breaking any other module in your application. For that, you need isolation (what the Object-Oriented folks call encapsulation), and for that, you need the module to have its own code, separate from the other modules. When you commit to this strategy, you will inevitably have some code duplication.

Naturally, there are plenty of legitimate reasons to DRY up code. But you seldom have to be completely DRY, nor would that be ideal.

So if you want to know when to be DRY, the code that you should DRY up is the code that you want to work the same way everywhere, and be able to maintain it from a single location.

  • 2
    Even a dry wine has some moisture :) – Berin Loritsch May 31 at 17:26
  • Well yeah... i think that it would be "nicer" to place a single line of code in both buttons that give the same output. It seems like copy-pasting makes it unreadable to others. – Volpym May 31 at 17:27
  • 1
    @Volpym: In light of this answer; we adhere to DRY to avoid coupling; if you have repetition, but both copies keep changing together in largely similar ways, it creates all kinds of problems. However, sometimes two peaces of code are only superficially similar, or only similar initially; they end up evolving in different directions. DRY-ing up such code early or carelessly would then cause unwanted coupling. Sometimes you can tell that this is the case from the start, but often not - thus the practice to wait for 3 or more examples before you generalize. – Filip Milovanović May 31 at 23:45
  • @Volpym: "It seems like copy-pasting makes it unreadable to others" - no, that's pretty wrong, copy-pasting does not change readability at first place - the copied code is as readable or unreadable as the orginal. But that is not the point of DRY code - making code DRY is about exactly the 2 points mentioned in Robert's last sentence, nothing else. If you don't care for it, you create maintainability issues, but not because of bad readability. – Doc Brown Jun 1 at 5:47
  • Worth it saying that some times, the code to be DRY up is not evident. It might take several iterations over the code. After a while some patterns or behaviours appears here and there. Certain blocks of code start looking similar. Not all the duplicated code is caused by copy-paste. – Laiv Jun 1 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.