Joshua Bloch at Google (formerly at Sun) has an excellent presentation entitled How to Design a Good API and Why It Matters. For each major point, he does a good job of showing both good and bad design examples from the Java APIs.

I’ve recently been reading Framework Design Guidelines which provides guidance on designing class libraries for .NET. It also provides insight into the design and creation of the .NET class libraries.

Coming from Java, it’s interesting to see how the two development cultures are reaching similar conclusions about library design. For example, the Framework Design Guidelines provides a strong case for using classes rather than interfaces for exposing abstractions. (You can read the details here). After being in the factory/interface camp for a long time, I’ve come around to this point of view as well. That’s not to say that I don’t believe in using interfaces, just that they tended to be overused. And as mentioned in the article, “class-based APIs can be evolved with much greater ease than interface-based APIs”.

Joshua’s presentation favors unchecked exceptions over checked exceptions. To many Java programmers this may sound like sacrilege but it’s consistent with .NET exception handling. In an interview with Anders Hejlsberg, Bruce Eckel indicates that he used to think that checked exceptions were really great. But often, they felt like handcuffs. After working in C# for several months I don’t miss them at all. Obviously I still use exceptions, just not exceptions that have to be declared in method signatures. In Java we often cheated — declaring that a method threw the most general type of exception and then documenting the specific exceptions that the caller might be interested in handling. If we had declared the specific exceptions instead then we’d have to change the method signature if we needed to add more. That, in a nutshell, was the major disconnect with checked exceptions.