The Artima Developer Community
Sponsored Link

Designing by Dictatorship, Examples, and Tests
A Conversation with Elliotte Rusty Harold, Part VII
by Bill Venners
August 25, 2003

<<  Page 2 of 3  >>

Advertisement

Design by Writing Examples

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 getNextSibling and 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, JDOM's Attribute class has eight different methods to read an attribute value depending on whether you want to get it back as an int, a float, a double, a Boolean, a String, or a Martian.

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.

<<  Page 2 of 3  >>


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us