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

[Chris Pickett]

Don't you like spaghetti?

Kyle Lahnakoski wrote:
> 
> 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
>>
>>  
>>
> 
>