Leaky abstraction: Difference between revisions
No edit summary |
web link with the source of the term, improved link labels |
||
| Line 1: | Line 1: | ||
A '''leaky abstraction''' is an incomplete implementation of an [[abstraction]]. The term is a [[misnomer]] in that it refers to a specific [[implementation]] of an abstraction, not the abstraction itself. Within the [[software industry]], leaky abstractions are a common source of [[software bug]] |
A '''leaky abstraction''' is an incomplete implementation of an [[abstraction]]. The term is a [[misnomer]] in that it refers to a specific [[implementation]] of an abstraction, not the abstraction itself. Within the [[software industry]], leaky abstractions are a common source of [[software bug|software bugs]]. |
||
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. |
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. |
||
| Line 7: | Line 7: | ||
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. |
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 message]]s 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 mode]] |
Obscure [[error message]]s 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 mode|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. |
||
== Web links == |
|||
* [http://www.joelonsoftware.com/articles/LeakyAbstractions.html Leaky Abstractions] - the original article by Joel Spolsky, who coined the term |
|||
Revision as of 18:48, 9 September 2006
A leaky abstraction is an incomplete implementation of an abstraction. The term is a misnomer in that it refers to a specific implementation of an abstraction, not the abstraction itself. Within the software industry, leaky abstractions are a common source of software bugs.
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.
Software is heavily reliant on 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 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.
Web links
- Leaky Abstractions - the original article by Joel Spolsky, who coined the term