Comment by karmakaze | Hacker News Reader

Comment by karmakaze | Hacker News Reader

> Using abstraction to manage complexity is fine. Obfuscation of complexity is not.

The post pushes these words around without giving any indication as to how to actually do anything. Seems like an example of moving definitions around.

The important thing when dealing with complexity is to decompose it into simpler parts that combine neatly. This is one meaning of 'good abstraction'. I don't like the word abstraction, as I also don't like the word refactor--they almost explicitly sound like arbitrary collecting/moving things about.

The word I use is 'factor'. I say I'm factoring the code. Then you have to be able to name which factor a particular piece of code has dealt with. If you can't answer that, you're just moving stuff. And once that's done, it shouldn't immediately need to be redone/refactored.

If something is complex because it has N dimensions, then try to create N components to deal with each factor as is possible rather than create refactorings that deal with some combinations of dimensions that follow chronological developments rather than structural ones with empty seams.

I got the same feeling from this post. It admonishes creating poor or unnecessary abstractions without demonstrating how to identify and avoid the problem.

How can you look at one interface/abstraction/api and concretely say “this is sweeping complexity under the rug” - what exactly makes that a fact instead of just an opinion?

If you entangle different interfaces together in the same place, changing them becomes even more complicated and error-prone. So adhering to SOLID principles leaves you with hopefully less of a mess. Usually each interface has each their own nuances, but also how to compose them in scope, processing sequences and time, may introduce complexity, side effects and additional workarounds, or frameworks.

Don't just adhere to something blindly. Keep it as simple as possible and iterate on designs until they make practical sense. The focus is on concrete implementations and results.

Yes, it's otherwise all opinion and fashion.

One such is that all abstractions comes with costs, and that they are usually just indirections and filters for the real thing. The word itself, is tough to communicate clearly and reason about. Ditto on refactoring, which doesn't explain much as well.

Concretely, if you minimize dependencies, entanglement and compose a minimal solution well, it is easier to evolve the code later after learning more from practical experience and new ideas. So it's often about waiting until the benefits clearly outweighs the costs of abstraction.

I'd say obfuscation is creating a level of indirection just to look modular. Moving things complex dependent side effects into separate functions just hides what is going on instead of clarifying it.

  void MajorFunction( void ) {
        MinorFunction1();
        MinorFunction2();
        MinorFunction3();
  }

This can often be better inlined because then the complexity is obvious.

Naming and shares use can make this one or the other. If it is a specific sequence of things that are commonly done, then putting it in one place so an update will keep all call sites in-sync. A small and simple function can sometimes be worth it, as opposed to that which 'mechanically' done (by humans) not with semantic significance but rather 'I can dedup this'.

The litmus test is if a reader sees the function name called somewhere and presumes what that does. If there's high confidence (across all people) in that presumption being correct and if they were to look at the body would see it do precisely what they thought. It doesn't matter if it does it differently as long as it has the same result as the expectation. Also don't name it one thing and do two things in there.

Reply on news.ycombinator.com