commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodion Efremov <rodion.efre...@cs.helsinki.fi>
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
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message