Leaky abstraction
From Wikipedia, the free encyclopedia
 |
This article may contain original research or unverified claims. Please improve the article by adding references. See the talk page for details. (March 2009) |
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.
Contents |
[edit] Overview
Joel Spolsky published the concept as
The Law of Leaky Abstractions:
| “ | All non-trivial abstractions, to some degree, are leaky. | ” |
In the publication, Spolsky expresses this viewpoint, and supports it with reference to examples in software engineering, which is why this term is customarily used in the context of computer software and hardware.
[edit] 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. 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.
[edit] Generalized sense
From the perspective of Spolsky's Law of Leaky Abstractions, 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.
It is most likely[citation needed] this notion Spolsky intended to convey by expressing the viewpoint as a "law" and attributing the "leakiness" to abstractions, rather than to imprecise implementations.
[edit] 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.
In this way, the Law of Leaky Abstractions is a tautology. Any abstraction that isn't leaky cannot be distinguished from a fundamental truth. A fundamental truth is not properly an abstraction. Therefore, no abstractions are not leaky.
[edit] Examples
[edit] 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.
[edit] 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.
[edit] See also
[edit] External links
- The Law of Leaky Abstractions - the original article by Joel Spolsky, who coined the term
- Joel on API Apology - see Bram Cohen's response to Joel.
- Coding Horror: Respecting Abstraction - an article about abstractions by Jeff Atwood
- Article in Ward's Wiki (at c2.com)- (includes several cross-references to other interesting "Patterns" in the original WikiWiki).
