commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [Graph] the future of commons-graph and modularization
Date Sun, 26 May 2013 18:46:26 GMT
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.efremov@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-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
>

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


Mime
View raw message