[Gephi-plugins] SpanningTree Plugin Structure Question
carlschroedl at gmail.com
Wed May 16 03:53:30 CEST 2012
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.
- 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
- 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
No need to download the whole git repo, you can just skim via the web
I'm particularily confused about how I should organize the
- 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!
| carlschroedl at gmail.com | cschroedl at wisc.edu | http://carlschroedl.com/blog|
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gephi-plugins