Editorial Note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site. While you’re there, download NDepend and play around with it.
In 2002, Joel Spolsky coined something he called “The Law of Leaky Abstractions.” In software, an “abstraction” hides complexity of an underlying system from those using the abstraction. Examples abound, but for a quick understanding, think of an ORM hiding from you the details of database interaction.
The Law of Leaky Abstractions states that, “all non-trivial abstractions, to some degree, are leaky.” “Leaky” indicates that the abstraction fails to adequately hide its internal details. Imagine, for instance, that while modifying the objects generated by your ORM, you suddenly needed to manage the particulars of some SQL query. The abstraction leaked, forcing you to understand the details that it was supposed to hide.
Spolsky’s point may inspire a fatalistic feeling. After all, if the things are doomed to leak, why bother with them in the first place? But I like to consider it a caution against chasing perfection rather than a lament.
Abstractions in software help us the same way figurative language helps our prose. Metaphors and analogies offer ease of understanding, but at the accepted price of lost precision. If you press a metaphor enough, it will inevitably break down. But that doesn’t render metaphors useless — far from it.
Thus, if you have a leaky abstraction, you can take steps to “plug” it, so to speak. Spolsky says it himself, right in the law he coined: “all non-trivial abstractions are, to some degree, leaky.” We have the ability to lessen that degree.