Ironically the DRY principle has been the source of more programmers repeating themselves about a principal they've never bothered to look up the original definition of, than any other software development guideline
Comments
Log in with your Bluesky account to leave a comment
Several points to make:
1. Good design principles bear repeating.
2. Sometimes one author speaks to you where another doesn't.
3. I learned DRY in 1987 — long before Hunt & Thomas documented it in 2000.
4. I learned it before I learned OOP — it was not a nuanced discussion about abstraction.
Pretty much everything in the series Fowler edits on design patterns is essential IF you are working with frameworks/projects that use those patterns. E.g. PoEAA makes Rails make sense because Rails is literally selections from PoEAA verbatim.
Sometimes I wish folks would recommend reading some of the other patterns books before Design Patterns. Like Pattern Hatching, about what patterns are how to document them when you find them.
Or Smalltalk Best Practice patterns which is the best patterns book ever, even if it's a bit niche😂
One of my perennial aims when composing educational resources is to point younger devs back to classics. The amount of time I see wasted on game-of-telephone interpretations of concepts that were actually explained *really well* in their source material is substantial.
Judging by a recent newsletter I replied to 😉 I would respectfully suggest that you learned a different principle, perhaps by the same name. I was around on WikiWiki when everyone was discussing DRY, OAOO before they were written down, and it was never about mechanically eliminating duplicated lines
I will say that I speculate the "similar lines of code" interpretation of DRY really started taking off with the advent of automated refactoring tools which could spot those duplications mechanically.
Yeah and like, the chapter that defines it is quite good and nuanced and pretty clear on what constitutes "duplication". But I've seen so many people apply it as "ope I just typed the same thing twice, BEEP BEEP BEEP DUPLICATION" and then the inevitable "anti-DRY" backlash to that facile definition
Like many things in life, humans are drawn to our confirmation biases and pick sides without seeking to be more informed. How do you defuse those situations?
Comments
1. Good design principles bear repeating.
2. Sometimes one author speaks to you where another doesn't.
3. I learned DRY in 1987 — long before Hunt & Thomas documented it in 2000.
4. I learned it before I learned OOP — it was not a nuanced discussion about abstraction.
* POODR
* XP Explained
* Refactoring
* Design Patterns
* Pragmatic Programmer
And, no, I didn't get Design Patterns until I read other books on the subject. Back to that thing about some authors speaking to you and others not.
* Domain Driven Design
* Working Effectively with Legacy Code
* Growing OO Software
Pretty much everything in the series Fowler edits on design patterns is essential IF you are working with frameworks/projects that use those patterns. E.g. PoEAA makes Rails make sense because Rails is literally selections from PoEAA verbatim.
Or Smalltalk Best Practice patterns which is the best patterns book ever, even if it's a bit niche😂