5 ms·

I agree with this comment wholeheartedly. Too often DRY is blindly applied to every little piece of code... in ways that violate SRP and lead to a tightly coupl

by jtdev 8y ago

I agree with this comment wholeheartedly. Too often DRY is blindly applied to every little piece of code... in ways that violate SRP and lead to a tightly coupled mess of code. It seems that DRY is the most easily understood of the SOLID concepts, and is therefore, unfortunately, over applied by many developers without an understanding the downstream affects.

layer8 8y ago
Nitpick: DRY isn't directly a SOLID concept. I find SPOT (Single Point Of Truth) to be more to the point than DRY, because it is explicitly about semantics and not about mere syntactic repetition.
- darkerside 8y ago
  > explicitly about semantics and not about mere syntactic repetition I'm hoping I remember to steal this later!
- JamesBarney 8y ago
  How have I never seen SPOT. I've read about the idea many times over the last ten years, but weirdly enough I've never seen it put it into an acronym. I feel like rules of thumb in software never quite make it until they're an acronym. I mean honestly the SOLID advice is pretty terrible, but is so often repeated because it has such a great acronym.
  - acje 8y ago
    What is suboptimal about SOLID? I’m about to buy into it so I’d like to know.
    - JamesBarney 8y ago
      Bout to see a movie with my wife so here's just a short description for now. SRP. Advice everyone can agree on, but not very actionable. I've seen a dev make a change to conform to SRP while another dev argued the change was bad because it violated SRP. Open/closed principle if you look at it's origin this is just terrible advice. So everyone tortures this advice until it says something different Liskov substitution principle - sure, but as a top 5 most important idea in oop Interface segregation principle - sure Dependencies inversion principle - I don't think abstractions are always better than concrete representations. In fact a lot of times they're worse. Humans are trouble at learning abstractions. So bad in fact they can learn abstractions from the concrete so much easier than from abstractions. And this is a huge cost to readability, and it's harder to get correct.
- hliyan 8y ago
  The problem with these acronymed principles is that there are always programmers who will treat them as religion (and senior programmers who will enforce it as such).
BeetleB 8y ago
Nitpick: The original DRY principle in The Pragmatic Programmer was about not repeating requirements. If two pieces of code are very similar, but have to do with different requirements (e.g. business logic), then DRY suggests you not abstract it any further. DRY, as a principle, is very good, and I've not seen a case of proper use being problematic. As the parent said: >The question to ask is not, are these similar, but will they act and change in the same ways (to your best knowledge) both now and in the future? If they represent different requirements, then the answer to the question is usually "No." So do not couple them together with an abstraction. If you do, you are not invoking DRY. You're just creating spaghetti.

by jtdev 8y ago

layer8 8y ago

Nitpick: DRY isn't directly a SOLID concept. I find SPOT (Single Point Of Truth) to be more to the point than DRY, because it is explicitly about semantics and not about mere syntactic repetition.

darkerside 8y ago
> explicitly about semantics and not about mere syntactic repetition I'm hoping I remember to steal this later!
JamesBarney 8y ago
How have I never seen SPOT. I've read about the idea many times over the last ten years, but weirdly enough I've never seen it put it into an acronym. I feel like rules of thumb in software never quite make it until they're an acronym. I mean honestly the SOLID advice is pretty terrible, but is so often repeated because it has such a great acronym.
- acje 8y ago
  What is suboptimal about SOLID? I’m about to buy into it so I’d like to know.
  - JamesBarney 8y ago
    Bout to see a movie with my wife so here's just a short description for now. SRP. Advice everyone can agree on, but not very actionable. I've seen a dev make a change to conform to SRP while another dev argued the change was bad because it violated SRP. Open/closed principle if you look at it's origin this is just terrible advice. So everyone tortures this advice until it says something different Liskov substitution principle - sure, but as a top 5 most important idea in oop Interface segregation principle - sure Dependencies inversion principle - I don't think abstractions are always better than concrete representations. In fact a lot of times they're worse. Humans are trouble at learning abstractions. So bad in fact they can learn abstractions from the concrete so much easier than from abstractions. And this is a huge cost to readability, and it's harder to get correct.
hliyan 8y ago
The problem with these acronymed principles is that there are always programmers who will treat them as religion (and senior programmers who will enforce it as such).

BeetleB 8y ago

Nitpick: The original DRY principle in The Pragmatic Programmer was about not repeating requirements. If two pieces of code are very similar, but have to do with different requirements (e.g. business logic), then DRY suggests you not abstract it any further. DRY, as a principle, is very good, and I've not seen a case of proper use being problematic. As the parent said: >The question to ask is not, are these similar, but will they act and change in the same ways (to your best knowledge) both now and in the future? If they represent different requirements, then the answer to the question is usually "No." So do not couple them together with an abstraction. If you do, you are not invoking DRY. You're just creating spaghetti.