commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodion Efremov <>
Subject Re: [Graph] the future of commons-graph and modularization
Date Sun, 26 May 2013 16:10:40 GMT
Simone Tripodi kirjoitti 26.05.2013 18:35:
> Hi all, mates,
> after a long while I haven't touched commons-graph, I had the
> opportunity to get influenced by some activities at my paid work that
> made me think twice on what as been already done in that component,
> and would like to bring new experiences in.
> So, what I still like about it:
>  * graph APIs: the use of generics make the usage of graphes
> extensible and adaptable;
>  * fluent APIs: this is the most powerful feature IMHO that 
> simplifies
> the APIs usage;
> What I *don't* like anymore:
>  * poor modularization: commons-graph is ATM a big fat monolith;
>  * one single entry-point; for each new family of algorithm(s), new
> methods have to be added in the main Commons-Graph class.
> What I would like to propose to work _in a separated branch_, is
> trying to split the big monolith in smaller modules and separate APIs
> from related implementation as much as possible.
> Questions are:
>  * WDYT? :)

Might the API look like this?

public interface PathFinder<V, E, W> {
     public Path<V, E> search();
     public PathFinder<V, E, W> from( V source );
     public PathFinder<V, E, W> to( V target );
     public PathFinder<V, E, W> withHeuristic( HeuristicFunction<V, W> f 
); // for A* search.

... and then we would have, say, A* as follows:

public class AStarFinder<V, E, W> implements PathFinder<V, E, W> {
     public Path<V, E> search() {
         // A* magic here.

     ... implement the rest.

... with usage as follows:

Path<V, E> path = new AStarFinder<V, E, W>().withHeuristic( 
myFunkyHeuristic ).from( source ).to( target ).search();

This would seem like eliminating the need for CommonsGraph -monolith at 
the cost of introducing new interfaces/abstract base classes for every 
type of algos out there, plus the actual implementation classes 
implementing the API.

>  * About release process: would it be acceptable, here in commons,
> release a single module - the only one that has been changed, I mean 
> -
> without releasing the whole project?
>  * In case the answer to previous question is "no", would it make
> sense moving commons-graph to the Incubator (and possibly to TLP)?
> TIA, all the best!
> -Simo
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message