Tag Archives: google

Good APIs

At least in the Java world[1], good APIs are very rare. The vast majority of the APIs I’ve used in Java are at best mediocre, and I’ve run into some real stinkers (No fingerpointing here, but a lot of them are even in the standard library!).

Part of this is the fault of the language. Java code… tends to be ugly. It’s not a language which lends itself to really flexible syntax, and so you have to work really hard to produce powerful abstractions which are actually nice to use.

The only APIs I’ve encountered so far which have really made me sit up and go “Wow, that’s well designed” are Google Guice and Joda time. They have well thought out class hierarchies, good object oriented style[2], sensible use of fluent interfaces / method chaining and just generally well thought out interfaces and names.

They’re not perfect by any means, but they show promise that it really is possible to write good APIs for Java.

Anyone else know of other similarly well designed libraries?

[1] And, unfortunately, I lack much in the way of non-trivially large development in other languages. The Parsec API is nice, ‘though it gives me a headache sometimes. Haskell libraries in general look rather pretty, though I suspect that’s more a function of the language than the API design. I’m not really experienced enough in it to judge good API design.

[2] I’m not an OO fanatic. It has advantages and disadvantages, and sometimes you just want to use a different approach (I rather like FP for example). But one thing I’ve observed is that if you do it right, OO can have the effect of producing some astonishingly readable code. I don’t know either well/at all really, but this style of design seems much more common in Ruby, smalltalk, etc.

Baby’s first open source project

I’ve decided to start a new personal project, and I’m going to make it open source from day one. The project is called JTypeBuilder and is hosted at Google Code and released under an apache 2.0 license.

The basic idea is that it is used for generating data models and producing an awful lot of associated boiler plate code. It produces immutable classes for representing the data, mutable classes for generating the immutable ones and methods for passing back and forth between them. The immutable classes all have the obvious equals and hash code implementations, as well as a toString method which produces a JSON like representation of the class.

It currently just consists of a couple freemarker templates and some simple wrapper code for them. When I get around to it I’ll add a parser and command line interface for nice representation of the data models.

I have vague intentions of using this for some sort of simple ORM package. Another possibility is using it as part of a compiler backend for targeting the JVM – it can be used to generate the data types. All of this is in the future though – right now it’s simply a tool for reducing boiler plate code (and a fairly incomplete one at that).

Update: Phew. That was a succesful day. The parser and code generator now work, and are hooked together with an extremely rudimentary command line interface (it’s little more than a proof of concept). Still to do are improvements to the interface and customisability, as well as general improvements to code generation and parsing. Nonetheless, there is now a working tool there. Yay.

Actually, come to think of it, the biggest thing that needs fixing at the moment is the build.xml. It’s a really shocking piece of spaghetti XML put together with the intent of having something working quickly rather than actually producing a portable build script… Lots of hard coded paths.

Unexpectedly popular

Hmm. In keeping with google’s recently acquired fascination with me, my stupid little parsec example appears to be the third from the top when you google for haskell parsec. I find this vaguely alarming.