5 ms·

I've found that it's much more difficult to unwind an abstraction than create one. And having similar, even identical, code in multiple places isn't necessarily

I've found that it's much more difficult to unwind an abstraction than create one. And having similar, even identical, code in multiple places isn't necessarily a good reason to build an abstraction. 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?

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.
michael_j_ward 8y ago
You may be interested in Sandi Metz's article "The Wrong Abstraction." https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti...
- jtdev 8y ago
  Love this post from Sandi, it nicely articulates the problems with naive DRY interpretation/application. The comment section on the page exhibits the stubbornness (although well intentioned) of those who perpetuate this anti-pattern.
delusional 8y ago
DDD get's this right by focusing on the language of talking about the design. If you can't make a single description that succinctly and accurately formulates the purpose and mechanism of the abstraction, in a way that fits all cases. I generally find the abstraction to be a poor fit.
- darkerside 8y ago
  I've found DDD to be a great concept to apply to this problem. Define your domain based on business foundations that will last, and intelligent reusable code abstractions practically write themselves.
ummonk 8y ago
I agree that about not doing premature abstraction, and thinking about future evolution rather than just current similarity when deciding whether to abstract or not. However, I don’t think it is difficult to unwind an abstraction. You just go to all the usages of the abstracted entity and replace them with specific code. Doing the opposite on the other hand is much harder if you have multiple sites that do something similar but not in somewhat different ways because they were written separately - it is much harder to merge the usages into a single abstraction, for the same reason it is hard to switch between libraries that do the same thing because the different libraries have different APIs.
- darkerside 8y ago
  Why is it hard to merge them? If they're doing the exact same thing, replacing with an abstracted function should be straightforward. If they're doing different things, merging them may be unwise, since they may truly be different conceptually. On the other hand, I've definitely seen it become near impossible to unwind an abstraction once it starts getting used by other abstractions that are used in many other places in your code (multiply by as many levels or permutations as it takes to achieve desired level of complexity). Meanwhile, this poor function has been twisted to satisfy all these unreasonable demands from every corner of your codebase, and teasing it apart becomes an Herculean effort.
hliyan 8y ago
Agree. The same principle that applies to code, applies to design: should be optimized for reading, not writing. I currently know some developers who have trouble switching away from IntelliJ IDEA because without it they can't navigate the entire abstraction hierarchy they've created.

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.

michael_j_ward 8y ago

You may be interested in Sandi Metz's article "The Wrong Abstraction." https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti...

jtdev 8y ago
Love this post from Sandi, it nicely articulates the problems with naive DRY interpretation/application. The comment section on the page exhibits the stubbornness (although well intentioned) of those who perpetuate this anti-pattern.

delusional 8y ago

DDD get's this right by focusing on the language of talking about the design. If you can't make a single description that succinctly and accurately formulates the purpose and mechanism of the abstraction, in a way that fits all cases. I generally find the abstraction to be a poor fit.

darkerside 8y ago
I've found DDD to be a great concept to apply to this problem. Define your domain based on business foundations that will last, and intelligent reusable code abstractions practically write themselves.

ummonk 8y ago

I agree that about not doing premature abstraction, and thinking about future evolution rather than just current similarity when deciding whether to abstract or not. However, I don’t think it is difficult to unwind an abstraction. You just go to all the usages of the abstracted entity and replace them with specific code. Doing the opposite on the other hand is much harder if you have multiple sites that do something similar but not in somewhat different ways because they were written separately - it is much harder to merge the usages into a single abstraction, for the same reason it is hard to switch between libraries that do the same thing because the different libraries have different APIs.

darkerside 8y ago
Why is it hard to merge them? If they're doing the exact same thing, replacing with an abstracted function should be straightforward. If they're doing different things, merging them may be unwise, since they may truly be different conceptually. On the other hand, I've definitely seen it become near impossible to unwind an abstraction once it starts getting used by other abstractions that are used in many other places in your code (multiply by as many levels or permutations as it takes to achieve desired level of complexity). Meanwhile, this poor function has been twisted to satisfy all these unreasonable demands from every corner of your codebase, and teasing it apart becomes an Herculean effort.

hliyan 8y ago

Agree. The same principle that applies to code, applies to design: should be optimized for reading, not writing. I currently know some developers who have trouble switching away from IntelliJ IDEA because without it they can't navigate the entire abstraction hierarchy they've created.