Talk:Abstraction inversion

Facade pattern?

What about the Facade pattern? (Originally asked by Wlievens on 2004-05-16 12:12:29, linked by PJTraill 01:04, 6 December 2005 (UTC))

Abstraction, and what constitutes abstraction inversion

The enthymeme (syllogism with an unstated premise - PJTraill 23:50, 26 February 2006 (UTC)) I see in this entry is that abstraction inversion is bad. Perhaps I misunderstand, but isn't the point of abstraction to put simple wrappers around complex things? High level languages are simple constructs under which, at the lowest level, is assembly language; in general, code for a high level language using a well designed framework or library is very simple, but the assembly language equivalent is so complex that it is utterly beyond the capacity of humans to work with the same operations at the level of machine instructions. Yet by the description given in the article, this would seem to be abstraction inversion, which everyone seems to imply is bad. Similarly, writing functions seems to be an act of abstraction inversion as well: instead of typing out code for an entire sub-routine, the complex subroutine is packaged with a simple function's interface. Is this abstraction inversion and "the incorrect way" or is something amiss in the article, or my understanding? Am I mistaken? Is my example a bad example?

Would somebody who groks this please give a few good examples of what abstraction inversion is, and what it is not, and what the crucial differences are between the two?

FYI, I didn't fundamentally understand the insights behind data abstraction and object-oriented programming until I read the intro to Objective-C (published by Apple), which described abstraction with an analogy of the mechanical watch: the internals of the watch are incredibly complex, full of gears of different ratios, escapement mechanisms, springs, and co-axial shafts, but the interface uses data abstraction (in the mechanical/physical sense) to present us with an elegant, simple interface: two watch arms with their own states (namely, their position relative to the watch face), and a knob to adjust the states. That way, the user never has to bother with how it works (complex), just how to work it (simple). Yet, a casual glance at this seems to show that the watch "creates abstract (or simple) constructs on top of concrete (or complex) constructs. The correct way is considered to be the other way round — to create complex constructs on top of more basic constructs." (Quoted from the Wiki article.)

Is this correct? Is it possible that "the correct way" as described in this article is actually mistaken? Why would anyone want to increase complexity? I want my complexity to be canned away so I don't have to think about or deal with it.

Perhaps the article should be ammended so as to create less confusion. I looked up "abstraction inversion" here in order to clarify my confusion, but it has only furthered it.

(Contributed on 2006-02-03 06:28:19 by Berkana)

I agree that the whole thing is dubious, and I hope that the remarks on difficulties recognising it suggest as much, but I have a feeling there is something in it, and it would be useful to disentangle the whole thing. Other articles I have found on the internet have not been any clearer. PJTraill 23:45, 26 February 2006 (UTC)

I hope usefully extended, standard anti-pattern structure

I hope that my latest series of edits to this article is useful: it is the result of a fair amount of googling, but it may need some restructuring. I feel at any rate that it is becoming clearer what abstraction inversion is really about, in particular the problem of exposing too weak interfaces makes much more sense to me than too simple interfaces.

It also seems to me that we should try to develop a standard structure for anti-pattern articles, something like:

• description
• symptoms / recognition
• ill-effects
• cure
• examples from the real world
• a worked example, with code
• links

PJTraill 02:42, 27 February 2006 (UTC)

Bad Examples

Some of the examples in the "Examples" section are debatable at best, just plain wrong at worst.

• I'm not really sure why the author thinks that Java's Runnable.run interface is an abstraction inversion.
• The point about functors in the STL in C++ is wrong, assuming I'm understanding it properly. The STL specifically allows function pointers to be used as functors, so there's generally no need to create a new class (unless you need multiple instances for some reason).
• The microkernel argument is a bit controversial, and the description does not explain the reason it is thought to be an abstraction inversion (the reader would have to actually read the cited sources to find that out).
• The Scheme example is useless to any reader that is not intimately familiar with Scheme.
• Likewise, the Subversion example does not provide any value to a reader that is not familiar with the implementation details of Subversion, since none are provided.

The other examples seem relatively reasonable. However, I think a more concrete example (perhaps including actual code or at least pseudo-code) for this would be extremely helpful to readers.

REggert (talk) 20:59, 17 January 2008 (UTC)

I'm removing the Scheme example since not only is it useless to those not intimately familiar with Scheme, it's useless to those not intimately familiar with details of many different approaches to implementing full continuations for Scheme. As stated, it's also wrong (with respect to the semantics of Scheme and many common implementation approaches), and moreover misleading (in that people will get the wrong idea about tradeoffs between tail-recursive and imperative looping). Finally, the linked tunes.org discussion is confused: the problem being discussed is to do with the approach to implementing full continuations, not with tail recursion itself, despite what the author thinks. It might make sense to talk about abstraction inversion using full continuations as an example, since they're frequently used to implement many more specialized control structures (exceptions, non-local return, coroutines, partial/delimited continuations), but writing that up effectively starts to look out of place in an "Examples" section. All in all, the Scheme example must go. Leastfixedpoint (talk) 15:29, 16 January 2012 (UTC)

I removed: " An example from Java is the method Runnable.run(), required by the method Thread.run()."

This is really an incorrect example since Runnable is an interface, and yes that interface must be implemented by some other class that implements Runnable, but only then could you use the Runnable instance... Otherwise you have a function/method signature definition and nothing else, so it really is not this anti-patter at all.

I think the Math or System libraries could have better examples. Math could, if you for example you used Math.sin() and Math.cos() used Math.tan(), or something like that maybe?? The System library surely must have some examples.

Perhaps this is a java example, if you were to create a Thread that ran on a 100ms timer, and it called the garbage collector - that would be re-implementing the garbage collection in way?? 76.28.198.13 (talk) 00:32, 17 April 2009 (UTC)

Even worse, Lua recently added integer types that it uses for whole values. --Steinm07 (talk) 11:52, 24 March 2020 (UTC)

Examples still bad

Most examples are still bad as of 2015-01-27. They seem opinionated and poorly supported. It's very hard to understand, from this article and its examples, exactly what Abstraction Inversion is, and how it differs from plain Abstraction. This is a very poor article. 200.0.230.235 (talk) 15:48, 27 January 2015 (UTC)

Ironic Examples

Along the lines of the example regarding relational databases with weak query interfaces, it might be interesting to cite the Wikipedia itself as a similar case in point. — Preceding unsigned comment added by 129.89.10.146 (talk) 00:35, 27 February 2014 (UTC)

Using Private-Access-Modifier instead of Protected

At work we use the Eclipse platform. Often when I have the wish to implement the same functionality in my plugin, i run into the problem that the available code cannot be reused because a required methods is marked as private. If it were, one could simply overwritten or call it from a subclass. This leads to copy & paste programming. The interessting thing on that is that this is mentioned in the book "Contributing to Eclipse: Principles, Patterns, and Plug-Ins: Principles, Patterns and Plugins (Eclipse Series)" as normal. I suggest to add Eclipse as an example. —Preceding unsigned comment added by 84.159.57.133 (talk) 04:59, 14 May 2008 (UTC)