Search code examples
c#javaabstractionanti-patterns

Does single-paradigm OOP lead to abstraction inversion?


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?


Solution

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