Leaky abstraction

From Wikipedia, the free encyclopedia

A leaky abstraction is an unsatisfactory implementation of an abstraction. Unsatisfactory means any case when specific implementation details manifest themselves in some obstructive or 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

The term is attributed to software commentator Joel Spolsky, who 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 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; 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 prorata by the owners of all other notes), 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.

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. A newfangled sound card, for example, may be able to reproduce the same sounds as old sound cards, but it also may have new ways of failing. If the operating system's sound card abstraction didn't anticipate the new failure modes, the program will encounter a failure it couldn't anticipate and can't understand. This can result in an "unknown error" or similar error message being presented to the user.

[edit] See also

[edit] External links

[edit] Notes