principles:law_of_leaky_abstractions
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
principles:law_of_leaky_abstractions [2018-04-11 11:57] – [Example 1: Distributed Objects] 84.46.93.199 | principles:law_of_leaky_abstractions [2020-10-12 16:21] – old revision restored (2013-10-08 11:09) 159.69.186.191 | ||
---|---|---|---|
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 | + | 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 |
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: | 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: | ||
Line 124: | Line 124: | ||
(this example is taken from ((Joel Spolsky: // | (this example is taken from ((Joel Spolsky: // | ||
- | |||
- | ==== 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 " | ||
- | * 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: | ||
===== 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: | + | [[wiki: |
/ | / | ||
- | [[wiki: | + | /*[[wiki: |
===== Further Reading ===== | ===== Further Reading ===== |
principles/law_of_leaky_abstractions.txt · Last modified: 2021-10-18 21:51 by christian