Talk:Abstraction inversion

From Wikipedia, the free encyclopedia

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))

[edit] 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)

[edit] 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)