How to obey DRY principle

Question

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.

Answer 1

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.

Answer 2

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.