In software development , a leaky abstraction is an abstraction that should be ideally hidden. Leaky abstractions are considered problematic, since the purpose of abstractions is
The term “leaky abstraction” was popularized in 2002 by Joel Spolsky .  An earlier paper by Kiczales discloses some of the issues with imperfect abstractions and presents a potential solution to the problem of 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 the problematic cause of software defects: the reliance of the software developer on an abstraction’s infallibility.
Spolsky’s article gives an example of an abstraction that is most likely to be ignored, thus leaking complexity out of the abstraction back to 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 quotes many examples of leaky abstractions that create problems for software development:
- The TCP / IP protocol stack is the combination of the TCP protocol, qui tries to Provide reliable delivery of information, running on top of the IP protocol, qui 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 of the variable performance of the variable performance (throughput and latency).
- Iterating over a large two-dimensional array can be radically different performance if done horizontally rather than vertically, depending on which elements are stored in memory. One direction can vastly increase cache missesand page faults , both of which greatly delay access to memory.
- The SQL language abstracts the procedural steps for querying a database , allowing one to always define what one wants. But certain SQL queries are synonymous with other queries. On an Even Higher Level of Abstraction, ORM systems, qui isolate object-oriented code from the implementation of object persistence using a relational database, still forces the program to think in terms of databases, tables, and native SQL queries as soon as performance of ORM-generated queries becomes a concern.
- Although network filesystems like NFS and SMB, they can be local, the connection to the remote machine may be slow down or break, and the file stops acting as if it was local.
- Inversion Abstraction
- Dependency inversion principle
- Essential complexity
- Modular programming
- Separation of concerns
- Jump up^ 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.
- Jump up^ 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.