Principles Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Law Of Leaky Abstractions (LLA) ======

===== Variants and Alternative Names =====


===== Context =====
/* fill in contexts here: */
  * [[contexts:Architecture]] 
  * [[contexts:API Design]] 

===== Principle Statement =====

> All non-trivial abstractions, to some degree, are leaky.((Joel Spolsky: //[[http://joelonsoftware.com/articles/LeakyAbstractions.html|The Law of Leaky Abstractions]]//))

A solution is bad if 
a) the leakiness of abstractions is ignored (bad usage of an abstraction) or
b) the benefits of the abstraction cannot justify the disadvantages created by its leakiness (bad abstraction) or
c) the abstraction is more leaky as necessary (bad abstraction)

===== Description =====


===== Rationale =====
Abstractions are typically not perfect. Especially performance aspects are very hard to abstract away from. So there are cases when using the abstraction properly is not possible without knowing the basics underneath the abstraction. So developing and even more fixing defects in a system with leaky abstractions makes it necessary to know about all the details the abstraction is supposed to protect the developers from. Often abstractions reduce the effort to develop a feature while they increase the effort for fixing bugs. The benefits of an abstraction are only reached at the cost of some liabilities so an abstraction is only good when the liabilities are small enough compared to the benefits.

===== Strategies =====

  * //Make the abstraction less leaky.// There might be a way to reduce the leakiness of the abstraction.
  * //Find a better abstraction.// There might be a better abstraction which is less leaky.
  * //Remove the abstraction.// If the abstraction is so leaky that the leakiness creates more problems than the abstraction solves, it is better not to have it.
    * Especially refrain from stacking Frameworks on top each other (e.g. Spring in an EJB Container, etc.)


===== Caveats =====

The law of leaky abstractions by no means says that abstractions are generally a bad thing. Abstractions are extremely helpful and software development without abstractions is virtually impossible. So abstractions are good and developers should strive for creating good abstractions. But abstractions are never perfect and this has to be kept in mind.

See also section [[#contrary principles]].


===== Origin =====

Joel Spolsky: //[[http://joelonsoftware.com/articles/LeakyAbstractions.html|The Law of Leaky Abstractions]]//

===== Evidence =====
/* Comment out what is not applicable and explain the rest: */

  * [[wiki:Proposed]]

/*  * [[wiki:Examined]]*/
/*  * [[wiki:Accepted]]*/
/*  * [[wiki:Questioned]]*/

===== Relations to Other Principles =====

==== Generalizations ====

==== Specializations ====
  * [[Fallacies of Distributed Computing]]: The eight fallacies of distributed computing are abstraction leaks which are typically present in distributed systems. Normally it is not possibly to prevent them (so there might not be a better abstraction) but it is important not to ignore these abstraction leaks.

==== Contrary Principles ====
  * [[Keep It Simple Stupid]] (KISS): Creating good abstractions is sometimes complicated and ignoring leaks is simple.

==== Complementary Principles ====
  * [[Murphy's Law]] (ML): According to ML, any abstraction leak will eventually result in a mistake.
  * [[Model Principle]] (MP): ML might help finding the right abstraction, i.e. the one which is the least leaky.
  * [[Rule of Explicitness]] (RoE): RoE is another way to look at abstractions. Often abstractions create a level of implicitness. Abstraction leaks are one reason why explicit solutions can be considered preferable.
  * [[Easy to Use and Hard to Misuse]] (EUHM): The more an abstraction leaks, the less it can be considered hard to misuse.

==== Principle Collections ====


===== Examples =====

==== Example 1: String Classes In C++ ====

In C++ string literals such as ''"test"'' are of type ''char*'' which means pointer to a character. There is some range in the memory where a sequence of characters is stored and there is a pointer pointing to the first character. These strings are unhandy to use so there are string classes in C++ which abstract from these low-level strings which are simply a heritage of the C programming language C++ is built upon. These string classes are much more convenient to use and create the illusion of a built-in string type.

<code c++>
#include <iostream>

int main()
{
	std::string s = "Hello";
	s = s + " World";
	std::cout << s << std::endl;
}
</code>

In this code it looks like there was a native string type in C++. This is the abstraction. But the abstraction is leaky. The following code does not work:
<code c++>
#include <iostream>

int main()
{
	std::string s;
	s = "Hello " + "World";
	std::cout << s << std::endl;
}

</code>

So it would be better if C++ had a real native string type.

(this example is taken from ((Joel Spolsky: //[[http://joelonsoftware.com/articles/LeakyAbstractions.html|The Law of Leaky Abstractions]]//))


===== Description Status =====
/* Choose one of the following and comment out the rest: */
[[wiki:Stub]]
/*[[wiki:Incomplete]]*/
/*[[wiki:Complete]]*/

===== Further Reading =====
  * Joel Spolsky: //[[http://joelonsoftware.com/articles/LeakyAbstractions.html|The Law of Leaky Abstractions]]//
  * Joel Spolsky: //[[http://joelonsoftware.com/articles/LordPalmerston.html|Lord Palmerston on Programming]]// About some of the consequences of the Law of Leaky Abstractions.
  * Thomas Drakengren: //[[http://blog.drakengren.com/2005/09/05/the-law-of-leaky-abstractions-refined/|The Law of Leaky Abstractions Refined]]//
  * //[[http://discuss.joelonsoftware.com/default.asp?joel.3.199142.10|Two Kinds of Leaky Abstractions!]]//

===== Discussion =====

Discuss this wiki article and the principle on the corresponding [[talk:principles:Law Of Leaky Abstractions|talk page]].