[moomoo11]

Is the abstraction so that they can easily swap out pieces of the system without a single headache, or write effective tests, or to make it easy to operate in a soup of services? Because then it makes complete sense.

Like dependency injection is something that a lot of juniors struggle to understand. Or in larger applications DDD and all the crap that goes along with it.

[jvans]

There's a long list of things that I think are abused in an effort to save on some vaguely defined future cost that never seems to materialize. Some things off the top of my head:

* Interfaces(particularly in java) that have 1 implementation.

* Interfaces with many implementations but where each implementation is used in exactly 1 place.

* large inheritance hierarchies with generic type parameters. I'm sure there's a good use case for this but it's usually a pain.

* Writing "generic" code in an effort to make something re-usable when in reality the code has knowledge of every location it is used in and tightly couples all implementations

[cwilkes]

I actually like the “one interface with one implementation” as it makes for less surprises.

With an interface I know that only that method can be called. If a class is passed in i have no idea what methods going to be used. It also gives me a better feeling that the coder has in mind what they need a parameter to do without worrying that they are going to rely on a couple of othogonal methods to be called.

[Zanfa]

The "death by a thousand abstractions" problem must be one of the most difficult ones to solve. Each abstraction in isolation makes sense and looks like an improvement, but given a few years, the overall code becomes an inscrutable mess of layers upon layers of complexity, hiding away what it actually does.