Does single-paradigm OOP lead to abstraction inversion?

Question

For those of you who aren't familiar with the concept, abstraction inversion is the implementation of low-level constructs on top of high-level constructs, and is generally considered a bad thing because it adds both needless complexity and needless overhead. Of course, this is a somewhat imprecise, subjective definition.

In your opinion, does programming in a single-paradigm OOP language where everything must be part of a class and things like pointers aren't exposed, such as Java or C#, inevitably lead to abstraction inversion? If so, in what cases?

Answer 1

Java and C# have static methods which are equivalent to functions, so the language isn't forcing anything on you.

That said, Once I really got OO, I haven't had any desire whatsoever to go to another style of programming.

If your simple OO layer is covering something complex, I suggest that it's probably your code that's an issue. If OO is done right it should be simple all the way down to the metal.

Answer 2

real programmers can write FORTRAN in any language

in other words, it ain't the language, it's the programmer

Answer 3

I don't think a language like Java or C# suffers from this in any tangible way, simply because the libraries accompanying the framework are so rich that the need to break into another paradigm isn't really required for general programming.

That said, the rich libraries themselves can suffer from abstraction inversion however, because the internal implementations are often hidden, or key classes are sealed, developers attempting to extend these libraries are often forced into re-implementing/replicating functionality to successfully make use of extension points provided by the base class library - this is not so much a language issue, as a conscious choice made by the developer of the base class libraries, to avoid exposing functionality which may be brittle or change often with new releases of the .Net Framework/JDK.

Also because the .Net Framework / Java Runtime both allow for interop with other languages sitting atop the common runtime, the ability to target other paradigms (such as functional programming, dynamic languages etc.) can also provide another route to breaking away from single paradigm constraints.

Answer 4

Single-paradigm anything violates the First Commandment of Abstractions, which few people seem to know about and even less care about.

Thou shalt not make unto thee any abstraction that cannot be overridden if necessary, that thy code be free of ugly abstraction inversions.

No matter what your paradigm, once you start writing non-trivial code to solve real-world problems, you are going to end up with some things that just don't fit the paradigm very well. If you declare that that one paradigm is all there is, this is when things get ugly.

To mix a couple metaphors, when all you have is a mallet, everything starts to look like a peg, and if all your holes are round and you suddenly end up with some square pegs and you don't have any saws, (just mallets,) you've got yourself a problem.

There's no free lunch. Everything is a trade-off. The easier code becomes to write, the harder it becomes for someone else to read and maintain, or for you or anyone else to debug when problems occur below the level of abstraction that you're working at. (And they will eventually, because no abstraction is perfect.

This is the fundamental flaw with "helpful" technologies and paradigms such as managed code, garbage collection, JIT compilation and the "everything is an object" fiat. They impose a baseline level of abstraction that you are not allowed to reach beneath, and when something goes wrong below that level, there's nothing you can do about it. You're stuck working around a bad abstraction because you can't fix it.