Sponsored Link •
Bill Venners: What techniques did you use to help you discover where your API was good and where it wasn't.
Elliotte Rusty Harold: I am a fan of Extreme Programming, but since I am essentially working by myself at home, pair programming isn't an option. I do use unit tests heavily on almost all the classes. The only areas where I don't have serious unit tests, where I have some tests but not full coverage, are in serialization and in parsing. Because writing unit tests for serialization and parsing is just bloody hard, so far I haven't done it. I really need to, though, because guess where all the bugs show up? They show up in serialization and parsing, where I don't have good unit test coverage.
One of the things I did that helped a lot with the design of the API, as opposed
to debugging and testing it, is I went through my book Processing XML with
Java, which over the course of 1000 plus pages has many sample programs in
SAX, DOM, JDOM, TraX, and other APIs. I rewrote all those examples using
XOM. Sometimes I would realize I was missing some obvious method that
would make this easier. Also, after I got to the end of the book and I looked at
my code samples, I realized I never did use certain methods. So I took them out.
Or I only used a method once, but I could have used another method instead.
That's why I got rid of the
getPreviousSibling methods I originally had, for example. It just
became obvious after translating all the examples to XOM that those methods weren't necessary.
I think implementing all those examples helped clarify a lot of the thoughts I had about what was worth putting in the API and what wasn't. In some cases it proved I needed new things. In other cases it proved I could afford to take certain things out. Based on what I've heard from early adopters of XOM, it resulted in a pretty clean API. I don't hear a lot of calls for convenience methods that aren't there. It is very rare compared to JDOM for example, where a lot of people ask frequently for extra methods.
Bill Venners: They do? But JDOM already has a lot of convenience methods, and XOM has so few.
Elliotte Rusty Harold: But maybe I've got the right methods.
Bill Venners: Or perhaps it's cultural.
Elliotte Rusty Harold: Yes, maybe it's cultural. In XOM, they can see that
there's not a lot of chance of getting additional methods added. For example,
Attribute class has eight different methods to read an attribute
value depending on whether you want to get it back as an
String, or a
Bill Venners: What you're saying is that one of the techniques that helped you design XOM is that you used your API over and over in lots of different cases.
Elliotte Rusty Harold: Yes.
Bill Venners: You looked at your book and rewrote all your XML processing examples in XOM, and you learned what was and was not needed in the XOM API.
Elliotte Rusty Harold: Right, exactly.