Jump to content

Leaky abstraction

Edit links
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 201.216.245.25 (talk) at 21:07, 28 October 2009 (→‎Technical sense: - the claim that abstractions themselves cannot have leaks is unsourced and seems like original research). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

A leaky abstraction is a notion applied to implementations of an abstraction. This notion indicates that specific implementation details manifest themselves in a counter-productive way, thus interfering with the abstraction. The implementation details are said to "leak through" and interfere with the simplifying assumptions supposedly enabled by the abstraction.

Within the software industry, leaky abstractions are a common source of software bugs.

Technical sense

When applying the term to a specific instance, it is a misnomer. The implementation is leaky, not the abstraction. Abstractions are conceptual and are not susceptible to leaks [citation needed]. Abstractions may have other faults, such as ambiguities or contradictions. The term 'leaky abstraction' refers not to faults in the abstraction itself, only to faults in its implementation.

Generalized sense

All non-trivial abstractions resist complete implementation by their very nature. Consequently, implementation details will always leak through, regardless of how well-conceived, and no matter how rigorously they attempt to faithfully represent the abstraction. Sometimes the leaks are minor, other times they are significant, but they will always be present, because there is no such thing as a perfect implementation of an abstraction.

In this context, the term isn't a misnomer, since it applies to all implementations of all abstractions.

Philosophical sense

In an epistemological sense, the human concept of any abstraction is always an implementation of deeper abstractions, represented in mental concepts and verbal statements used to convey them. There is no generally agreed-upon deepest layer of abstraction. Much (if not most) of the field of philosophy is predicated upon searching for such a layer.

The idea that all sufficiently interesting abstractions are leaky thus has profound philosophical ramifications.

Consider the field of physics. A proton is an abstraction which is implemented, on a deeper level, by a set of quarks. The extent to which the nature of the quarks "leaks" through to the nature of the proton appears to depend largely on context such as temperature. However, there's no doubt that the quark implementation leaks through; otherwise, it would not be possible to know about quarks. Humans only know they exist based on the extent to which they leak through higher-level abstractions.

This is also covered in an article by Joel Spolsky, who is unfortunately getting the credit for the idea. The original paper is available at http://www2.parc.com/csl/groups/sda/publications/papers/Kiczales-IMSA92/for-web.pdf and should be cited as the primary reference.

Examples

Monetary value

Paper currency implements the abstract economic concept of monetary value. Conceptually, monetary value cannot be destroyed[citation needed]; yet a paper note can be. The physical nature of the implementation (the paper note) corrupts the conceptual nature of the abstraction (its monetary value). If a note is burned, the value is lost (to its owner, but gained pro rata by the owners of all other notes[citation needed]), even though such a result shouldn't be possible from the perspective of monetary ownership.

Computers

Computer hardware and software is heavily reliant on abstraction, and therefore subject to the consequences of leaky abstraction.

For example, many different brands of sound card exist, and each has different capabilities and methods of operation. It is the role of the computer's operating system to implement a sound card abstraction for programs, so that a program need not have knowledge about every possible sound card that may be present. The program tells the operating system's sound card abstraction what sound to make, and the operating system then tells the sound card to make the sound using the mechanisms and capabilities unique to that sound card. If the abstraction isn't leaky, then a program can take advantage of any sound card with no problems. If the abstraction is leaky, however, the program may run into trouble - the sound may come out differently depending on the sound card, requiring the program to compensate by incorporating logic specific to the sound card installed in the computer. For example, many early sound cards could only play a limited number of sounds simultaneously. In a computer game it is common for many sound effects to be played at once, possibly resulting in some sounds unexpectedly not playing.

Any API which behaves differently depending on the underlying implementation is considered leaky. If a program fails to compensate for leaky APIs, bugs can result.

Obscure error messages are a common observable effect of leaky abstractions in software.

For example, operating systems abstract away the details of mass storage from software, but invalid assumptions can still cause the software to fail in unexpected ways. Many programmers develop software on desktop PCs with internal mass storage that cannot be removed, but enterprise class networked storage can become temporarily or permanently disconnected from a running system. Failure to anticipate such events can result in an "unknown error" or similar message being presented to the user. In theory the file system APIs should be usable "as is" by all software without having to know the details of the underlying storage, but in practice, many applications will fail depending on the details. For a real world example, see this knowledge base article on Microsoft's support site describing the unexpected issues one might encounter opening Outlook PST files over a network.

See also

Notes

Retrieved from "https://en.wikipedia.org/w/index.php?title=Leaky_abstraction&oldid=322608296"