Friday, May 15, 2009

How many classes does it take to serialize a POJO?

(or: the usefulness of class count as metrics for simplicity)

A recent JSON package comparison got me thinking about perceived simplicity (or lack thereof) of libraries. While I do not really think number of classes is a generally useful metrics of a package (nor generally correlate with its fitness), I can at least see how an argument could be made that sometimes "small is beautiful" (especially if a more accurate metrics like resulting jar size was used) -- it would seem strange if supporting libraries are significantly larger than the main code of a plug-in or such.

But what I think is the actual fallacy is using number of implementation classes as some sort of proxy for simplicity of package; especially regarding being simple to use (intuitive, easy to use etc). As in assuming that a package with, say, 12 classes, is simpler to use than one with 250 classes. The problem is this: from user perspective, only those classes that user has to directly interact with really matter: they are the public API, and contain all the complexity user is faced with. Implementation classes seldom matter -- they are there, get used, but are not exposed to you. There is no cognitive load on such implementation details.

So back to the original question title asked: regarding Jackson specifically, how many classes do YOU as a developer really need to know to use it?

I think it can be as low as just one: the all-powerful (org.codehaus.jackson.map.)ObjectMapper.
For most users, that's the only class they need to be familiar with, from within Jackson class library.

And even power users only need to know a couple of additional classes:

  • (org.codehaus.jackson.)JsonFactory for constructing other things
  • (org.codehaus.jackson.)JsonParser if streaming parsing (or data binding, tree model) is needed
  • (org.codehaus.jackson.)JsonGenerator if streaming JSON writing (or bean, tree model serialization) is needed
  • (org.codehaus.jackson.)JsonNode if Tree Model is used for processing, instead of or in addition to streaming processing or data binding.

which would give us grand total of 5 classes you need to familiarize yourself with. And for good developers that deal with error cases, one more (JsonException) for bit more of error handling.

From there on, additional classes (exceptions, configuration objects) are only needed when more functionality is needed; and most of additional classes are rather simple: especially annotations which usually are little more than markers, tags.

In fact, another allegedly "simpler" with 7 classes probably requires you to know all them. And chances are there is less modularity in division of concerns, likely leaking unnecessary implementation details into API.

Of course, this is not the only problem with "classes as measure of complexity" idea -- having a properly modular API with more classes can be much more palatable than one with just a single monster swiss pocket knife class -- but it should be enough to get you thinking seriously whether to apply such simplistic metrics for evaluating simplicity.

Assessing simplicity has lots of complexity to it. And fundamentally, like beauty, simplicity is in the eye of beholder.

blog comments powered by Disqus

Sponsored By


Related Blogs

(by Author (topics))

Powered By

About me

  • I am known as Cowtowncoder
  • Contact me at@yahoo.com
Check my profile to learn more.