Jump to content

Talk:Abstraction (computer science)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Drable (talk | contribs) at 12:30, 29 April 2006 (Disambiguation link repair - You can help!). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

I think the current page misses the whole point. Making some minor adjustments to correct worst mistakes.


The words from the article could be divorced from the OOP POV thus, simply making it a programming language statement, as if a programmer were thinking about working on a project.


In computer science, abstraction is the analog of abstraction in mathematics. The mathematical technique of abstraction begins with mathematical definitions; this has the fortunate effect of finessing some of the vexing philosophical issues of abstraction.

Abstraction allows programmers to think simply about a problem, by deferring unimportant detail for later, while still allowing thought about more important goals, in stages of thinking, not all-at-once. For example, in both computing and in mathematics, numbers are concepts in the programming languages, as founded in mathematics. Implementation details depend on the hardware and software, but this is not a restriction because the computing concept of number is still based on the mathematical concept.

During software development, the client typically understands the application, and can understand the use of the work. The semantics of the application dictate the structure of the implementation.

For example, Linda abstracts the concepts of server and shared data-space to facilitate distributed programming; that is, the semantics of distributed processing were implemented in Linda. In Java, abstraction takes place at the level of extended data types. Such types are called classes, and objects are instances of said class. The concept of abstraction is itself a declarative statement in programming languages such as C++ or Java, using the keywords virtual or abstract, respectively, to decorate the class name. After such a declaration, it is the responsibility of the programmer to implement a class to instantiate the object of the declaration. Or, if the specification language is UML, for example, the abstract classes are simply left abstract during the architecture and specification phase of the project.

Thus, in the architecture stage, one could define an abstract data type called lookup table, where keys are uniquely associated with values, and values may be retrieved by specifying their corresponding keys. Such a lookup table may be implemented in various ways: as a hash table, a binary search tree, or even a simple linear list (which is actually quite efficient for small data sets). As far as client code is concerned, the abstract properties of the type are the same in each case.

The interface between components of an implementation forms a contract on agreed behaviour between components of the application. This interface can be sybmbolized in various ways, such as Ward Cunningham's CRC cards.

Some other languages that implement data abstraction include Ada and Modula-2.

[PROPOSE moving this back to the OOP page]

Abstraction in object oriented programming

Object-oriented languages are commonly claimed to offer data abstraction; however, the inheritance concept tends to put information in the interface that more properly belongs in the implementation; thus, changes to such information ends up impacting client code, leading directly to the fragile base class problem.

[propose a REPLACE of the Animals code with some Object diagram]

Further Reading

  • Abelson, Harold, Gerald Jay Sussman with Julie Sussman. (1996) ISBN 0262011530 Structure and Interpretation of Computer Programs (Second edition). The MIT Press


[LEAVE this in the abstraction page]

See also

The opposite of abstraction is instantiation.

This article (or an earlier version of it) contains material from FOLDOC, used with permission. Modify if needed.

169.207.115.74 22:50, 1 Nov 2003 (UTC)


I had a real hard time following your comments 169.207.115.74. I can't tell if you made all those comments or not. I made a recent change to the definition because it seemed to be poorly defined, and I researched it for about two hours online and in my text books. The best I could come up with was the definition found in a textbook used in MIT, which I referenced, and this is the page from that book: [1].

Your comments about not including a reference to OOP seem to me to be oriented towards optimized for purity at the expense of usefulness. As abstraction is a necessary concept of OOP and OOP has become mainstream, not referencing OOP would be incomplete though the comments about OOP listed above are definitely POV.

While the animal code is not the best, code is helpful and I would recommend it stay or be replaced by better. Adding a diagram could help though.

FWIW MikeSchinkel 11:15, 2 Nov 2003 (UTC)


Shouldn't the heading title "Layers of Abtraction" really be "Levels of Abstraction"? If no one objects, I will change it. Montalvo 01:18, 29 November 2005 (UTC)[reply]