[Soot-list] Structure of Soot (OO Design)

[Kyle Lahnakoski]

Thank you for putting a metric to how difficult it is to understand Soot 
code. Over the last month I have been refactoring Soot beyond 
recognition, trying to isolate the optimization routines from the 
parsing and code generation. Soot feels as though every class depends on 
every other class; a huge ball of spaghetti where pulling on any strand 
pulls brings the whole ball with it.

Your graph certainly verified my feeling.



Hayden Melton wrote:

>Hi all,
>
>
>I’m a PhD student at the University of Auckland, New Zealand. As part of my
>research I am doing empirical studies on a corpus of Java applications looking
>at their (OO) design. If you are a developer of Soot you might be interested in
>the metrics I have collected on it. They are available as graphs here:
>
>http://www.cs.auckland.ac.nz/~hayden/junitEvolution.htm
>
>There’s an explanation of what the graphs mean on my research page:
>
>http://www.cs.auckland.ac.nz/~hayden/research.htm
>
>Briefly, there are a lot of classes in Soot involved in a big (compilation)
>dependency cycle (or to use the graph-theory term: strongly connected
>component). I think this is bad, though it’s only one aspect of the quality of
>a design. Other applications like ArgoUML and Azureus have exhibited this large
>SCC characteristic too. As a result of my contact with the Azureus developers
>they have begun refactoring Azureus.
>
>In any case, check it out if you’re interested in the design of Soot; or OO
>Design and metrics in general.
>
>/
>Hayden Melton
>
>_______________________________________________
>Soot-list mailing list
>Soot-list at sable.mcgill.ca
>http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
>  
>


-- 
----------------------------------------------------------------------
Kyle Lahnakoski                                       kyle at arcavia.com
(416) 892-7784                                    Arcavia Software Ltd