Leaky abstraction

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" the simplifying assumptions supposedly enabled by the abstraction.

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

Overview

The term is widely associated with 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.

Basic sense

In a basic sense, the term is a misnomer because it is the implementation details that "leak" through, not the abstraction itself.

Extended notion

In an extended sense, the term is not a misnomer, because, according to Spolsky, *all* non-trivial abstractions resist complete implementation by their very nature. Consequently, implementation details will always 'leak through', regardless of how well-thought they are. 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.

Monetary Value

An implementation of an abstraction is leaky if the properties of the implementation bleed through the abstraction. Paper currency implements the abstract economic concept of monetary value. Conceptually, monetary value cannot be destroyed; yet a paper dollar can be. The physical nature of the implementation (the paper dollar) corrupts the conceptual nature of the abstraction (its monetary value). If a dollar is burned, the value is lost, 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.

Hardware example

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 the most 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.

External links

• The Law of Leaky Abstractions - the original article by Joel Spolsky, who coined the term