User Tools

Site Tools


principles:law_of_leaky_abstractions

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
principles:law_of_leaky_abstractions [2013-08-02 16:14]
christian [Specializations]
principles:law_of_leaky_abstractions [2018-04-11 11:57] (current)
84.46.93.199 [Example 1: Distributed Objects]
Line 1: Line 1:
-====== Law Of Leaky Abstractions ======+====== Law Of Leaky Abstractions (LLA) ======
  
 ===== Variants and Alternative Names ===== ===== Variants and Alternative Names =====
Line 13: Line 13:
 > All non-trivial abstractions, to some degree, are leaky.((Joel Spolsky: //[[http://joelonsoftware.com/articles/LeakyAbstractions.html|The Law of Leaky Abstractions]]//)) > 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 solution is bad if 
-a) the leakiness of abstractions is ignored (bad usage of an abstraction) or +  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 +  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)+  the abstraction is more leaky than necessary (suboptimal abstraction)
  
 ===== Description ===== ===== Description =====
 +
 +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.
 +
 +A typical problem with leaky abstractions is that the leakiness is ignored. This does not directly mean that the abstraction itself is bad. Often the situation without the abstraction would be worse so it's good to have it. Nevertheless its unavoidable leaks have to be kept in mind. See [[#Example 1: Distributed Objects|example 1]].
 +
 +There are also situations where the abstraction is not crafted well. Sometimes there is a way to make the abstraction better (see [[#Example 2: String Classes In C++|example 2]]) but sometimes the whole abstraction is wrong and not having it would be better.
  
  
 ===== Rationale ===== ===== Rationale =====
 +
 +  * Bad usages of abstractions are plain wrong. There is no doubt that they should be avoided.
 +  * Suboptimal abstractions can be made better. There are unnecessary leaks and each leak is a possibility for a future usage fault (see [[Murphy's Law|ML]]). As the leaks are unnecessary, there are ways to improve the abstraction so this one s bad.
 +  * 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. Bad abstractions are worse than no abstraction at all, so they should not be employed.
  
  
Line 29: Line 39:
   * //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 41: Line 52:
  
 Joel Spolsky: //[[http://joelonsoftware.com/articles/LeakyAbstractions.html|The Law of Leaky Abstractions]]// Joel Spolsky: //[[http://joelonsoftware.com/articles/LeakyAbstractions.html|The Law of Leaky Abstractions]]//
 +
 +The blog article has another focus as it rather explains LLA as an effect rather than an engineering advice. Because abstractions are leaky, developers should and have to know the details abstractions try to protect them from. The principle aspect is only a side aspect there but the main focus here.
 +
  
 ===== Evidence ===== ===== Evidence =====
Line 57: Line 71:
 ==== 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.   * [[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 66: Line 86:
 ===== Examples ===== ===== Examples =====
  
-==== Example 1: String Classes In C++ ====+==== Example 1: Distributed Objects ==== 
 + 
 +There is plenty of middleware which centers around the notion of distributed objects: RMI, CORBA, DCOM, ... These technologies abstract away from the fact that the objects are not local but distributed over the network. They create the illusion that calling all objects are local. But all these technologies are leaky abstractions. There is no way to abstract from the fact that calling a remote object may fail. The network connection may break down, the remote machine may not be available, etc. Furthermore there are completely different performance characteristics of remote calls. There is some unavoidable latency and no abstraction what so ever can change this. 
 + 
 +This does not mean that these technologies are generally bad. There is a value in these abstractions but the leaks have to be kept in mind. Ignoring the fact that remote calls may fail will result in fragile systems. If the distributed system to develop should be robust, there has to be code handling failing remote calls. And for performance reasons, remote interfaces have to be crafted in a way that remote calls are minimized. So for example [[patterns:Data Transfer Objects]] are employed in order to transfer larger chunks of data instead of making a remote call for every access to a getter method. 
 + 
 + 
 +==== Example 2: 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. 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.
Line 96: Line 123:
 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]]//))
 + 
 +==== Example 3: List of further examples ==== 
 + 
 +  * The virtual address space is leaky. Paging leads to a loss of performance. And page faults show up for example while iterating over a two-dimensional array. 
 +  * Platform details are leaky. The Java Virtual Machine does a pretty good job abstracting from the underlying operating system. But at least  when it comes to accessing files based on file paths, the underlying file system structure leaks through. On Windows you have "C:\" whereas on Unixoid systems you have "/usr", "/etc" and stuff. 
 +  * SQL is leaky. Some queries have a considerably lower performance than others despite being semantically equivalent. 
 +  * Network file systems (SMB, NFS, etc) are leaky because they are remote. The connection may break down and the access is much slower than local file access. 
 +  * The finiteness of real-world machines leaks. Programming languages are said to be Turing complete. They theoretically are as powerful as a Turing machine. In fact they are not. Turing machines are conceptual automata with infinite memory. But in the real world memory is finite. There can be OutOfMemoryErrors: RAM and hard disks and any other kind of storage can and do get full.
  
  
 ===== Description Status ===== ===== Description Status =====
 /* Choose one of the following and comment out the rest: */ /* Choose one of the following and comment out the rest: */
-[[wiki:Stub]]+/*[[wiki:Stub]]*/
 /*[[wiki:Incomplete]]*/ /*[[wiki:Incomplete]]*/
-/*[[wiki:Complete]]*/+[[wiki:Complete]]
  
 ===== Further Reading ===== ===== Further Reading =====
principles/law_of_leaky_abstractions.1375452882.txt.gz · Last modified: 2013-08-02 16:14 by christian