|This article needs additional citations for verification. (March 2011) (Learn how and when to remove this template message)|
In software development, a leaky abstraction is an abstraction that exposes details and limitations of its underlying implementation to its users that should ideally be hidden away. Leaky abstractions are considered problematic, since the purpose of abstractions is to manage complexity by concealing unnecessary details from the user.
The term "leaky abstraction" was popularized in 2002 by Joel Spolsky. An earlier paper by Kiczales describes some of the issues with imperfect abstractions and presents a potential solution to the problem by allowing for the customization of the abstraction itself.
The Law of Leaky Abstractions
As coined by Spolsky, the Law of Leaky Abstractions states:
|“||All non-trivial abstractions, to some degree, are leaky.||”|
This statement highlights a particularly problematic cause of software defects: the reliance of the software developer on an abstraction's infallibility.
Spolsky's article gives examples of an abstraction that works most of the time, but where a detail of the underlying complexity cannot be ignored, thus leaking complexity out of the abstraction back into the software that uses the abstraction.
Effect on software development
As systems become more complex, software developers must rely upon more abstractions. Each abstraction tries to hide complexity, letting a developer write software that "handles" the many variations of modern computing.
However, this law claims that developers of reliable software must learn the abstraction's underlying details anyway.
Spolsky's article cites many examples of leaky abstractions that create problems for software development:
- The TCP/IP protocol stack is the combination of the TCP protocol, which tries to provide reliable delivery of information, running on top of the IP protocol, which provides only 'best-effort' service. When IP loses a packet TCP has to retransmit it, which takes additional time. Thus TCP provides the abstraction of a reliable connection, but the implementation details leak through in the form of potentially variable performance (throughput and latency both suffer when data has to be retransmitted).
- Iterating over a large two-dimensional array can have radically different performance if done horizontally rather than vertically, depending on the order in which elements are stored in memory. One direction may vastly increase cache misses and page faults, both of which greatly delay access to memory.
- The SQL language abstracts away the procedural steps for querying a database, allowing one to merely define what one wants. But certain SQL queries are thousands of times slower than other logically equivalent queries. On an even higher level of abstraction, ORM systems, which isolate object-oriented code from the implementation of object persistence using a relational database, still force the programmer to think in terms of databases, tables, and native SQL queries as soon as performance of ORM-generated queries becomes a concern.
- Although network file systems like NFS and SMB let one treat files on remote machines as if they were local, the connection to the remote machine may slow down or break, and the file stops acting as if it was local.
- Abstraction inversion
- Dependency inversion principle
- Essential complexity
- Modular programming
- Separation of concerns
- Spolsky, Joel (2002). "The Law of Leaky Abstractions". Retrieved 2010-09-22. - a blog post by Spolsky that asserts that all non-trivial abstractions are 'leaky' and therefore problematic.
- Kiczales, Gregor (1992). "Towards a New Model of Abstraction in the Engineering of Software" (PDF). Retrieved 2010-02-03. - a paper by Gregor Kiczales that describes the problem of imperfect abstractions and suggests a programming model for coping with them.