DRY reminds us that every repetitive behavior in the code can and should be extracted (e.g. within a function) for later reuse. Having two fragments of the same code in your codebase isn't good.
Close, but not quite. Your code can be overly DRY as well, wherein you abstract too much out into functions and macros and lambdas and...heaven help us. That's when the code becomes a big pile of DRY spaghetti. GCC's libstdc++ is a great (terrible) example of this.
Instead, I recommend applying DRY with what I call the "rule of threes": If you repeat something twice, it is not an automatic candidate for DRY. If you repeat something three or more times, seriously consider abstracting!
DRY isn't about code duplication - it's about knowledge duplication. Sometimes two pieces of code that 'do' the same thing are actually 'about' different things. For instance (a very simple instance):
This is when coupling goes wrong. It seems like a really stupid example, but when DRY goes wrong it's the same thing, but usually just a few steps removed (classes instead of variables, for instance).
When Sandi Metz talks about the 'wrong' abstraction, she means that it's bad when we couple concepts together in code that are actually independent of each other even though the code 'looks' the same. We couple together pieces of knowledege that are actually independent. My favourite number and the second prime number are the same... but they're really nothing to do with each other. One expresses an eternal fact about three, and the other is much more subject to change...
The final kicker: you won't be able to spot knowledge duplication as easily as you can spot code duplication. It becomes apparent much, much later as you build your program.
Pretty good. One major correction, however...
Close, but not quite. Your code can be overly DRY as well, wherein you abstract too much out into functions and macros and lambdas and...heaven help us. That's when the code becomes a big pile of DRY spaghetti. GCC's
libstdc++is a great (terrible) example of this.Instead, I recommend applying DRY with what I call the "rule of threes": If you repeat something twice, it is not an automatic candidate for DRY. If you repeat something three or more times, seriously consider abstracting!
To correct the correction ;)
DRY isn't about code duplication - it's about knowledge duplication. Sometimes two pieces of code that 'do' the same thing are actually 'about' different things. For instance (a very simple instance):
!!! LET'S DRY IT !!!
but now I ❤️ four!
oh noes!
This is when coupling goes wrong. It seems like a really stupid example, but when DRY goes wrong it's the same thing, but usually just a few steps removed (classes instead of variables, for instance).
When Sandi Metz talks about the 'wrong' abstraction, she means that it's bad when we couple concepts together in code that are actually independent of each other even though the code 'looks' the same. We couple together pieces of knowledege that are actually independent. My favourite number and the second prime number are the same... but they're really nothing to do with each other. One expresses an eternal fact about three, and the other is much more subject to change...
The final kicker: you won't be able to spot knowledge duplication as easily as you can spot code duplication. It becomes apparent much, much later as you build your program.
Honestly best explanation of DRY gone wrong I've seen.
Yes, exactly. Good insight. It's not really much different from what I was trying to say, although you've beautifully expanded the point!
This. So much this.