First off, I generally don’t worry about DRY until there are 3 instances, not 2. With only 2, it’s really easy to over-generalize or have a bad structure for the abstraction.
But otherwise, I disagree with the article. If it’s complicated enough to bother abstracting the logic, the worst that can happen in the above situation is that you just duplicate that whole class once you discover that it’s not the same. And if that never happens, you only have 1 copy to maintain.
The code in the article isn’t complicated enough that I’d bother. It even ends up with about the same number of lines of code, hinting that you probably haven’t simplified things much.
The code in the article isn’t complicated enough that I’d bother. It even ends up with about the same number of lines of code, hinting that you probably haven’t simplified things much.
I think it’s a good example of the problem though. People take that same idea and apply it too liberally. The point isn’t that specific code, it’s about not apply DRY to code that’s coincidentally identical.
But otherwise, I disagree with the article. If it’s complicated enough to bother abstracting the logic, the worst that can happen in the above situation is that you just duplicate that whole class once you discover that it’s not the same. And if that never happens, you only have 1 copy to maintain.
That’s… Not at all true in practice. What often happens with these “DRY” abstractions when they’ve been improperly applied is you end up with an inheritance hierarchy or a crazy template or some other thing. You’re really lucky if you can just copy some code and find your way out of the weeds.
There are plenty of bad abstractions in the wild and novices applying DRY is a common source of them.
First off, I generally don’t worry about DRY until there are 3 instances, not 2. With only 2, it’s really easy to over-generalize or have a bad structure for the abstraction.
But otherwise, I disagree with the article. If it’s complicated enough to bother abstracting the logic, the worst that can happen in the above situation is that you just duplicate that whole class once you discover that it’s not the same. And if that never happens, you only have 1 copy to maintain.
The code in the article isn’t complicated enough that I’d bother. It even ends up with about the same number of lines of code, hinting that you probably haven’t simplified things much.
I think it’s a good example of the problem though. People take that same idea and apply it too liberally. The point isn’t that specific code, it’s about not apply DRY to code that’s coincidentally identical.
That’s… Not at all true in practice. What often happens with these “DRY” abstractions when they’ve been improperly applied is you end up with an inheritance hierarchy or a crazy template or some other thing. You’re really lucky if you can just copy some code and find your way out of the weeds.
There are plenty of bad abstractions in the wild and novices applying DRY is a common source of them.