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-10-08 11:09]
christian
principles:law_of_leaky_abstractions [2018-04-11 11:57]
84.46.93.199 [Example 1: Distributed Objects]
Line 88: Line 88:
 ==== Example 1: Distributed Objects ==== ==== 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 ​fro 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.+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. 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.
Line 124: Line 124:
  
 (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.txt · Last modified: 2018-04-11 11:57 by 84.46.93.199