Hacker News Reader

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?

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.

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.

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.

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.

What is suboptimal about SOLID? I’m about to buy into it so I’d like to know.

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.

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).

> explicitly about semantics and not about mere syntactic repetition

I'm hoping I remember to steal this later!

You may be interested in Sandi Metz's article "The Wrong Abstraction."

https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti...

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.

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.

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.

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.

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.

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.

> it's just splitting code into functions

I feel you underestimate the concept of "function". We all tend to do that because they are abstractions so ubiquitious that we cannot even imagine world without them. But it was not always so. Here's the first time someone speculates about "subroutines" (1953): https://web.archive.org/web/20150628022047/http://www.laputa...

>I personally wouldn't even call the author's given example abstraction, it's just splitting code into functions. Splitting code into functions is mostly an aesthetic and "reading comprehension" choice

Actually "splitting code into functions" was one of the first major abstractions invented for structured programming.

Not to mention that functional programming (and lambda calculus) are all about functions...

> And never abstract in advance

I would contest that, when the abstraction you're going for is actually a library. If I want to send SMS then pulling in the Twilio SDK is a useful and effective abstraction compared to rolling my own API client.

Similarly, MVC is a useful abstraction too. I'd prefer to kick start a Rails project in a few minutes as opposed to piecing together a full web stack, and I'd take a desktop framework over building all of that from scratch.

There does seem to be a great deal of confusion about what abstraction actually means. I've seen 4000-line Python modules full of indirection up and down the inheritance chain described as "nicely abstracted" rather than "unmodifiable spaghetti." The reasoning was fuzzy: "you instantiate it and it just does everything you need." But you can't build anything new with it, and it makes so many assumptions about its environment that you can't change anything around it. However you define "abstraction", I'd call that a "boat anchor" instead.

Another good rule of thumb: if you can't find a good name for the thing you want to abstract, it might be a bad idea.

To me it's all about putting related stuff together. LoC doesn't matter much, to me either way. Here's some more of my thoughts on the matter: https://nixpulvis.com/ramblings/2019-01-05-splitting-cats-an...