Hi Rodion, > > Might the API look like this? > [...]
more or less :) Introducing kind of "PathFinder" interface, as main entry point for shortest path algorithms, but keeping the current chin builders - as you notice, `withEuristhic` makes sense for A* only, when current fluent interfaces drive users on choosing the right algorithm, with right inputs, via a "state-machine" which is clever than a simple builder pattern. Anyway > > 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. you got the idea, nice to see we are on the same path!!! :) I'll prepare a more concrete proposal in a branch, hope to read reviews from your side! :) All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, May 26, 2013 at 6:10 PM, Rodion Efremov <rodion.efre...@cs.helsinki.fi> wrote: > 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-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
