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

Contents

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


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

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