3 ms·

In my experience, the abstractions that are helpful are the ones that significantly reduce complexity in the code using them by hiding details that we rarely ne

In my experience, the abstractions that are helpful are the ones that significantly reduce complexity in the code using them by hiding details that we rarely need to see. Put another way, they separate interface from implementation and the resulting interface is significantly simpler. That lets us reason about our code at a higher level without getting bogged down in unnecessary details. Most of the problematic abstractions I see in the real world don’t hide much complexity but still introduce extra complexity of their own (with the latter even becoming greater than the former in the worst cases) or often leak so we still have to drill down through the abstraction to understand what’s happening anyway. Arguably, these are just two sides of the same fundamental flaw.

plaguuuuuu 10y ago
A lot of the most annoying and time-consuming abstractions at my company are, ironically, geared towards maintainability/extendability concerns. We have wrappers around generic web service callers that rely on factories that create classes that convert between web service objects and domain objects, all wired together using interfaces for each service class and an IoC container, with its own XML configuration file. The irony is that if the web service were to change its interface, you'd have to change like 10 files instead of like.. a single conversion function somewhere. And to begin with you had to create those 10 files in the first place. It's absolute fucking madness.
- Chris_Newton 10y ago
  That looks like a great (that is, horrifying) example of the problem where the extra complexity introduced by the abstractions is actually greater than any complexity they successfully hide. It’s frightening how often this happens at all scales, from little utility functions with names that are several times as long as their implementations right up to the kind of enterprise architecture that nightmares are made of.
eternalban 10y ago
> the abstractions that are helpful are the ones that significantly reduce complexity Accepted! (Did I mention anything about complexity?)
- Chris_Newton 10y ago
  No, you didn’t. I was trying to characterize the “poor attempts at abstraction” you mentioned.

plaguuuuuu 10y ago

A lot of the most annoying and time-consuming abstractions at my company are, ironically, geared towards maintainability/extendability concerns. We have wrappers around generic web service callers that rely on factories that create classes that convert between web service objects and domain objects, all wired together using interfaces for each service class and an IoC container, with its own XML configuration file. The irony is that if the web service were to change its interface, you'd have to change like 10 files instead of like.. a single conversion function somewhere. And to begin with you had to create those 10 files in the first place. It's absolute fucking madness.

Chris_Newton 10y ago
That looks like a great (that is, horrifying) example of the problem where the extra complexity introduced by the abstractions is actually greater than any complexity they successfully hide. It’s frightening how often this happens at all scales, from little utility functions with names that are several times as long as their implementations right up to the kind of enterprise architecture that nightmares are made of.

eternalban 10y ago

> the abstractions that are helpful are the ones that significantly reduce complexity Accepted! (Did I mention anything about complexity?)

Chris_Newton 10y ago
No, you didn’t. I was trying to characterize the “poor attempts at abstraction” you mentioned.