Principles Wiki

User Tools

Site Tools

You are here: Principles Wiki » Principles » Law Of Leaky Abstractions (LLA)
principles:law_of_leaky_abstractions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
Next revisionBoth sides next revision
principles:law_of_leaky_abstractions [2013-06-28 20:15] – created christianprinciples:law_of_leaky_abstractions [2013-08-29 12:15] – christian
Line 1: Line 1:
-====== Law Of Leaky Abstractions ======+====== Law Of Leaky Abstractions (LLA) ======
  
 ===== Variants and Alternative Names ===== ===== Variants and Alternative Names =====
Line 16: Line 16:
 a) the leakiness of abstractions is ignored (bad usage of an abstraction) or 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 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)+c) the abstraction is more leaky than necessary (bad abstraction)
  
 ===== Description ===== ===== Description =====
Line 22: Line 22:
  
 ===== Rationale ===== ===== 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 ===== ===== Strategies =====
Line 29: Line 29:
   * //Find a better abstraction.// There might be a better abstraction which is less leaky.   * //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.   * //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.)
  
  
Line 56: Line 57:
  
 ==== Specializations ==== ==== 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 ==== ==== Contrary Principles ====
 +  * [[Keep It Simple Stupid]] (KISS): Creating good abstractions is sometimes complicated and ignoring leaks is simple.
  
 ==== Complementary Principles ==== ==== 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 ==== ==== Principle Collections ====
Line 96: Line 103:
 So it would be better if C++ had a real native string type. 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]]//))+(this example is taken from ((Joel Spolsky: //[[http://joelonsoftware.com/articles/LeakyAbstractions.html|The Law of Leaky Abstractions]]//)))
  
  
Line 106: Line 113:
  
 ===== Further Reading ===== ===== 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 ===== ===== Discussion =====
  
 Discuss this wiki article and the principle on the corresponding [[talk:principles:Law Of Leaky Abstractions|talk page]]. Discuss this wiki article and the principle on the corresponding [[talk:principles:Law Of Leaky Abstractions|talk page]].
principles/law_of_leaky_abstractions.txt · Last modified: 2021-10-18 21:51 by christian