views:

444

answers:

4

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?

+1  A: 

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.

Bill K
I agree with your "down to the metal" statement. On the other hand, I'm concerned that OO has become almost an end in itself. I've seen too many beautifully built, but way over complicated, OO apps.
Mike Dunlavey
I won't go so far as to say too much OO is bad, but I will gladly admit that it's a pretty big hammer that can be swung in many different ways, and without thought, most are not very helpful.
Bill K
Static methods are only thought of as "equivalent to" simple functions because there's no other way to do it. When it's decided that all holes must be round to satisfy the king's sense of aesthetics, you end up doing some really ugly things to all the square pegs that keep popping up. Soon you end up with ugly static methods everywhere because there are so many concepts that just don't map well to the "object" paradigm.
Mason Wheeler
Or you don't know how to map your concepts to the Object Paradigm. All I said is that I haven't ever had a problem with coding as OO, but if you can't find a way to map your particular problem, perhaps another language fits you better. I wasn't suggesting static methods were a good solution either--I said that they are an indication you're not getting the OO bit--maybe you just don't think in OO and you do think in Functional. I have the opposite problem, I don't know how to draw a decent, understandable design diagram of a large functional system.
Bill K
+4  A: 

real programmers can write FORTRAN in any language

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

Steven A. Lowe
A: 

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.

Bittercoder
+2  A: 

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.

Mason Wheeler