[Gephi-plugins] SpanningTree Plugin Structure Question

Carl Schroedl carlschroedl at gmail.com
Wed May 16 03:53:30 CEST 2012


Hey all,

I've picked up my SpanningTree plugin project after a long hiatus.
Current capabilities are pretty basic:

   - The plugin shows up in Gephi's UI as a statistic
   - A simple form lets users select between all available
   SpanningTreeAlgorithm implementations (Hooray Lookup library!)
   - I've finished one SpanningTreeAlgorithm implementation - Kruskal's
   - Correct minimum spanning trees are found using Kruskal's algorithm.
   The total weight of the edges in treturns the count Per Tim/phreacocious'
   suggestion, the edges in the minimum spanning tree are marked with a new
   attribute. Marking the nodes thusly permits them to be used in Filters.
   - The plugin is designed so that it will be easy to add additional
   SpanningTreeAlgorithm implementations without modifying anything else in
   the SpanningTree plugin.

Todo:

   - lots, but most immediately I want to modify the GUI to ask each
   algorithm for algorithm-specific options. Correspondingly, I need to define
   these interfaces/abstract classes:
      - SpanningTreeAlgorithmOptions -  to specify the algorithm-specific
      options
      - SpanningTreeAlgorithmOptionsUI - to display the appropriate UI
      controls for adjusting the algorithm-specific options

Before I go any further, I'd appreciate some comments on the plugin's
structure...
No need to download the whole git repo, you can just skim via the web
interface:
https://github.com/carlschroedl/gephi/tree/master/SpanningTree/src/org/gephi/statistics/spanningtree

I'm particularily confused about how I should organize the
SpanningTreeAlgorithm implementations:

   - Inside classes that extend the abstract SpanningTreeAlgorithm class, I
   have been adding all helper classes as private inner classes (example
   KruskalsAlgorithm.java). Should I continue to do this, or should I just
   pull the helper classes out into their own individual files? I started
   nesting the helper classes as inner classes to avoid cluttering the plugin
   with lots of helper class files that only pertain to one
   SpanningTreeAlgorithm implementation, but now the implementation files are
   growing huge and I heard that unit-testing inner classes is a pain.
   - Would it be better to move implementations of SpanningTreeAlgorithm to
   their own plugins? In this way developers working on new
   SpanningTreeAlgorithms could place helper classes in their own files,
   improve unit-testability, etc. On the other hand, there are at least 3
   other easy-to-implement spanning tree algorithms, and some
   hard-to-implement linear-time ones, so this approach would add at least 5
   plugins to Gephi by the time that I'm done, and possibly more if the hard
   algorithms are tackled. Each of these plugins would be tiny. Is this
   something we want? How much clutter are we hoping for on the plugin level?
   Is it ok to add as many plugins as possible, or is it better to include
   more functionality in each plugin?
   - Another way to phrase this is: "of the following, where should helper
   classes be placed?"
      - In one plugin and in...
         - one file as inner classes
         - many files as regular classes
      - In many plugins and many files as regular classes

Thanks in advance for your suggestions! I'm new to software design but I'm
getting better :) Please let me know if I can clarify anything!

-- 

Carl Schroedl

| carlschroedl at gmail.com | cschroedl at wisc.edu | http://carlschroedl.com/blog|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gephi.org/pipermail/gephi-plugins/attachments/20120516/654b0a64/attachment.html>


More information about the gephi-plugins mailing list