The Nightstar Zoo

Nightstar IRC Network -
It is currently Thu Apr 27, 2017 1:40 pm

All times are UTC - 6 hours [ DST ]

Post new topic Reply to topic  [ 2 posts ] 
Author Message
PostPosted: Mon Oct 02, 2006 8:52 pm 
From ... 77237.aspx

Interface Design and the Law of Leaky Abstractions

Programmers are always trying to make things simpler, usually by making them more complex. Interface too complicated? Need a bit of extra functionality? Want to work closer to the problem? Add a layer of abstraction to the code. As most programmers know, this is, ironically, usually the right solution. Abstraction is critical to breaking a problem down into managable chunks. Of course, as a friend of mine once said, in programming every problem can be solved by adding another layer of abstraction, except for the problem of too much abstraction.

Joel Spolsky once made an important observation about abstractions, which he dubbed the Law of Leaky Abstractions. As he explains, an abstraction has leaked when a user of the abstraction needs information, data, or knowledge of the underlying implementation or interface. And Spolsky's observation is an inconveniently true one.

The Law of Leaky Abstractions: Every non-trivial abstraction leaks.

So what does this mean if you're designing an interface? You've got some kind of lower-level functionality that you're exposing, so that consumers for your interface can use the functionality of your much simpler interface without regard to the ugly details of the underlying interface. Your new abstraction is so good that nobody will want to use the underlying stuff anymore. In fact, you're so confident in your new interface that you don't need to expose the old one, right? Wrong. Your abstraction will leak. No matter how careful you are in creating the abstraction, there will be a scenario where users of your interface will need knowledge of the underlying implementation or access to the underlying functionality. Your abstraction didn't fail. It just leaked. But if you've hidden the underlying functionality, then you've just disabled every scenario in which a leak occurred.

Corollary to the Law of Leaky Abstractions: An abstraction should not hide or disable that which it abstracts.

This applies to wizards, COM interfaces, API functions, communication protocols, and all other abstractions. I worked on an IRC bot a while back which could take third-party plugins. We abstracted away the IRC protocol into an object-oriented interface that would track channel state information locally and present modes and information through accessors in the interface. We implemented channel.IsModerated to wrap mode 'm', channel.IsTopicLocked to wrap mode 't', and so on with all of the standard modes. We couldn't think of any reason to need the IRC protocol directly, so we didn't expose it.

One network, however, had implemented a custom mode 'U' to block URLs in channel. Obviously we hadn't include an accessor to this mode (we weren't psychic), so our abstraction leaked, and our bot's plugins couldn't use this new mode. The solution was not to add a channel.IsBlockingURLs accessor to our class. That would lead to interface bloat (and a waste of our time) as we have to add a new accessor for each custom one-off mode or protocol extension. No, the solution was to enable plugins to program through our interface and write directly to the protocol, which we did in our next release.

The Law of Leaky Abstractions says that you can never completely abstract away the whole protocol/interface/function/etc. So don't try. Abstractions are still very useful. They make things easier for the 80% case and improve efficiency. But when designing your abstraction, be careful that you don't also disable the 20% case in the process.

 Post subject:
PostPosted: Fri Nov 03, 2006 11:42 am 
Nightstar Graveyard Daemon
User avatar

Joined: Mon Jun 03, 2002 8:30 pm
Posts: 1071
Location: Wouldn't you rather observe my Velocity?
I had this lesson literally beaten into my head as a teenager. I wrote some code that made an incomplete abstraction and then prevented the user from overriding the software's choice.

Upon review of the app, my boss balled up a fist and bopped me on the top of my noggin with every word:

Don't. Write. Code. That. Thinks. It. Is. Smarter. Than. The. User.

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 posts ] 

All times are UTC - 6 hours [ DST ]

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group