I wasn't awake enough to take notes on Brian Marick's keynote, but I should have - it was a great talk. In any event, I'm attending Michael Feather's talk on API design. He's starting with a common problem developers have: say you want to fetch mail in code. You then have to dig through the API documentation (or in VW, the PDF docs) to figure out how to use the mail code. Interestingly enough, raw API doc isn't that useful without accompanying "how to" type doc. IMHO, what you really want in this case is example code - the API documentation doesn't help you initially (although it will help you down the road, when you want to do more. On the Smalltalk side, you then go browse code, but that works just as well - even though it's "politically incorrect" compared to massive API doc :) )

This particular example is of interest to me because I did screencasts on mail sending and receiving just last week - and I didn't have to create a new class just to figure that out. After perusing the example code in ours doc, I just tossed a few lines into a workspace and tried them out. Once I had that down, I just did the screencasts :). Ultimately, you do what I did in BottomFeeder - create a class that wraps mail sending (or receiving), and deal with your own API, and then have a simple place where the underlying vendor API is isolated and easy to manage.

So API Design: The art of creating interfaces that are useful to clients and extensible for future needs. Not all interfaces are APIs.

Unit Tests: They really do need to be isolated (i.e., not dependent on network communication, database results, etc).

API Development is hard work because:

• APIs live forever
• Meaning, Mistakes live forever
• Early choices can close off future desires

Interesting comment next: Avoid Static Methods. I would have said that Sun simply screwed up, and didn't create real objects. If classes in Java were actual objects, this problem wouldn't exist. Heh - he also recommends against using Sealed, Final, and non-virtual. Again, those aren't features - they are bugs.

Here's a good piece of advice: write code that uses your own APIs. If it's too hard for you to use, then what will your clients think? As well - supply your tests to the end users (developers). There's no good reason not to.