I think it is more extensible to hold a collection of different storages than to have to make subclasses for every combination of them. Right now I have a subclass implementation working for my use case, but it isn't the cleanest.
On Tue, Oct 28, 2014 at 12:06 PM, Peter <[email protected]> wrote: > Hi Erik, > > a list of extended storages sounds interesting, still I would like to > understand better the usecase. > > When you would use e.g. a subclass with separate DataAccess objects what > would be more complex or impossible compared to a list of extended storages? > > Kind Regards, > Peter. > > > On 27.10.2014 22:35, Erik Formella wrote: > > It looks like to be able to support turn costs we have to sacrifice the > ability to use any other extended storage. > > I am thinking I can refactor GraphStorage to use an > ExtendedStorageManager. It would allow us to write things like: > > TurnCostStorage turnCostStorage = > graph.getExtendedStorageManager().get("turn_costs"); > > instead of doing: > > if (graph.getExtendedStorage() istanceof TurnCostStorage) { ... } > > > This is just my first guess at what the interfaces should look like, but > does that seem like a change you would appreciate in GraphHopper? > > > _______________________________________________ > GraphHopper mailing > [email protected]https://lists.openstreetmap.org/listinfo/graphhopper > > > > _______________________________________________ > GraphHopper mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/graphhopper > >
_______________________________________________ GraphHopper mailing list [email protected] https://lists.openstreetmap.org/listinfo/graphhopper
