One of the things that has been popping into my mind recently is centered around the notion that all abstractions are leaky in the sense that no abstraction can actually completely hide the layers for what its built on. Joel Spolsky penned
"the Law of Leaky Abstractions" which basically states that all abstractions leak through aspects of the layers for which they are built on, and therefore the user of the abstraction winds up being exposed to more complexity than otherwise necessary and/or originally intended. It is interesting in reading some of the internet material that has been published around the subject of leaky abstractions in that folks have extended the notion beyond computer science into the world of
physics and even other disciplines like
philosophy, etc.I wonder if when building a good abstraction, you should just acknowledge that all abstractions will be leaky and design-in the leakiness. In this pursuit, we should use the laws of
Progressive Disclosure whereby the user of an interface or software is only exposed those concepts which are minimally required to accomplish the desired task. I highly subscribe to the usefulness of progressive disclosure techniques, as they tend to keep simple stuff simple and can make learning a new thing easier.
One of the painful things about abstractions is they sometimes get in your way -- a good abstraction can step aside for situations like this. An excellent example of leaky abstractions and progressive disclosure techniques that I can think of that meld very well is in the area of computer language compilers: some of the better ones expose a way for the programmer to "drop down" into assembler, right in the middle of their higher-level language constructs, and allow the programmer to tailor the code specifically for a given hardware device. This capability of drop down allows the programmer to cope with, in a very natural way, leaks like: new instructions that the higher level language (i.e. the abstraction) has not been built to specifically exploit, or even something as tailoring specific condition codes that can arise on newer hardware that need to be handled for correct code behavior. This concept demonstrates good "
Progressive Leakiness" in that most programmers get the 100% value of the language abstraction not needing to be exposed to the more complex assembler language techniques (progressive disclosure) but permits specific situations to be coded for which could not be handled by the abstraction or wind up causing the abstraction to misbehave (leaky abstraction).
It seems to me that SCA might be a good candidate for a Progressive Leakiness focus. I could envision casting an SCA Reference to a JAX-WS, for instance, to do specific Web Service stuff that would not otherwise be available or even maybe appropriate through the SCA abstraction.
I don't know, maybe wrong -- I could be in need of a vacation too, I can't tell....
