windowsdev pro

 Most of us are familiar with Spolsky's Law of Leaky Abstractions. But what about cases where abstractions leap beyond their boundaries to the point where they change or destabilize functionality or systems beyond what should be their sphere of control?

In a recent article I mentioned two of these abominable abstractions (such as the IE7 Opacity/ClearType Caper and a problem with file permissions not inheriting with SQL Server 2005 directories on Windows Server 2003). But in both cases, these abominations were caused by someone trying to 'help'.

Anyone else bumped into either of these issues? What about your own abominable abstractions - got any that you'd like to share?  

Or, got any ideas on how we could codify some legitimate complaints into a real 'law' of abominable abstractions? 

In the .Net Framework, there are quite a few. But my personal favorite is System.Net.FtpWebRequest. FTP is an entirely different animal than HTTP, but Microsoft saw fit to create the FtpWebRequest to use a programming interface that mimics the HTTP Session-less Request/Response model, and makes it extremely difficult to find out what the actual transmission messages are. In fact, FTP is "File Transfer Protocol," which means that its chief purpose is to serve as an intermediary for remote file system operations, such as uploading and downloading of files, browsing the virtual file system, etc. It is also a connected protocol, which retains a connection to the server until the session is over. But the FtpWebRequest class behaves as if each Request/Response is occurring completely separately from the next.

This class is also designed to behave best with Microsoft FTP servers, although most FTP sessions tend to occur with non-Microsoft FTP servers, as FTP is less in-use these days. I found it so opaque that I wrote my own FTP client classes which are modelled to behave like a real FTP session, and can interact well with any remote FTP server.

 Yeah, that's a great call. I actually don't know of anyone that uses it for the reasons that you've outlined. In the past I've tried using it myself, but ultimately ended up rolling my own after getting sick of dealing with some of the major problems that you've outlined. (I also looked into a number of 3rd party FTP libraries, but always found that I didn't really like how they 'offered too much' in terms of functionality and so on. This was about 4 years ago though... so I'd hope that some decent options would be available now.) 

But I think that your assesment is spot on: this abstraction was abominable in that the authors of the System.Net.FtpWebRequest clearly overstepped the bounds of what they were trying to abstract/encapsulate by trying to make it mimick an HTTP request. A colleague of mine once used to refer to issues like this in the framework by stating: "And that's why you shouldn't let interns write code...".