Structure of the Java API (OO Design)
Hi all,
I am a PhD student at the University of Auckland, New Zealand. As part of my research I have performed an empirical study on a large corpus of Java software (which includes applications like Ant, Tomcat, Eclipse, Netbeans, Azureus). You can see how the structure (design) of the classes in the Java API compares to these other applications in the corpus here:
http://www.cs.auckland.ac.nz/~hayden/corpus.htm
The results show that the largest dependency cycle in the Java API involves around 900 classes. Other applications also have long dependency cycles (e.g. Soot, ArgoUML, Azureus, Eclipse). It's thought that such long cycles are bad I present the arguments why on my research page (linked to from the above page).
(Oh, the to find the Java API search for "jre" -- that will take you to the appropriate row in the results table).
/
Hayden Melton
> You can see how the
> structure (design) of the classes in the Java API
> compares to these other applications in the corpus
> here:
Translation: You can see a bunch of poorly presented graphs here:
> http://www.cs.auckland.ac.nz/~hayden/corpus.htm
> The results show that the largest dependency cycle in
> the Java API involves around 900 classes.
I'll take your word for that.
> It's thought that
> such long cycles are bad
By whom? Apart from you, that is.
> I present the arguments
> why on my research page (linked to from the above
> page).
If there was a clear concise summary of this explanation I couldn't find it before I lost all respect for your communication skills.
So, did you have a question as such? Or were you hoping to stimulate discussion about whatever your point was supposed to be? Or did you just want to advertise your uninspiring research?
This subject might have been interesting. You rendered it as dull as possible. Recommended reading: Tufte.
> Translation: You can see a bunch of poorly presented graphs here:
>
> > http://www.cs.auckland.ac.nz/~hayden/corpus.htm
I'll agree with this - they ARE very difficult to interpret.
But I love the premise of studying those existing large code bases.
> By whom? Apart from you, that is.
I first saw these ideas coming from Bob Martin at ObjectMentor. I don't recall if he gave numerical criteria, but the cycles and fan-in and fan-out were ideas that he developed pre-Java, published in "C++ Report".
>
> If there was a clear concise summary of this
> explanation I couldn't find it before I lost all
> respect for your communication skills.
>
> So, did you have a question as such? Or were you
> hoping to stimulate discussion about whatever your
> point was supposed to be? Or did you just want to
> advertise your uninspiring research?
>
> This subject might have been interesting. You
> rendered it as dull as possible. Recommended reading:
> Tufte.
Man, that's the truth. I've lusted after those three Tufte books for years, but never bought them for my own. They are magnificent stuff. The graph showing Napolean's march to Moscow and back is priceless.
%
> I first saw these ideas coming from Bob Martin at
> ObjectMentor. Etc.
I'm not as such arguing with the premise - it may well be true. Just the presentation as fact.
> Man, that's the truth. I've lusted after those three
> Tufte books for years, but never bought them for my
> own. They are magnificent stuff. The graph showing
> Napolean's march to Moscow and back is priceless.
The only tiny problem for me is that the example diagram that Tufte concocts to "prove" his premise about data ink is absolutely unusable. And in fact most of The Visual Display of Quantitative Information is in fact opinion. While I mostly agree with the opinions, nevertheless I would have prefer to have seen usability studies to prove the points he makes.
