-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactored Graph Traversal Implementation #258
Conversation
Signed-off-by: yash-bharatiya_psl <[email protected]>
Signed-off-by: yash-bharatiya_psl <[email protected]>
Signed-off-by: yashTEF <[email protected]>
There are some other places where redundant parameters are being used.
The above deadline parameter is not needed, as the validation for deadline is done later in the ExternalRouteService
Also in getVoyageNumber() we don't require the parameters However, the above are not removed as I assume this is present to simulate real world application If needed these can be removed too. |
|
||
List<String> allVertices = dao.listLocations(); | ||
allVertices.remove(originUnLocode); | ||
allVertices.remove(destinationUnLocode); | ||
|
||
int candidateCount = getRandomNumberOfCandidates(); | ||
List<TransitPath> candidates = new ArrayList<>(candidateCount); | ||
List<TransitPath> candidates = new ArrayList<>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please revert this. It is inefficient to create an empty list when capacity is known.
fromDate = nextDate(date); | ||
toDate = nextDate(fromDate); | ||
date = nextDate(toDate); | ||
List<TransitEdge> transitEdges = new ArrayList<>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please revert this. It is inefficient to create an empty list when capacity is known.
How sure are you that this hasn't introduced subtle bugs? This is the logic that came from the original project: https://dddsample.sourceforge.net. It was never intended to be very accurate. As long as it still does something plausible, it's fine to make these changes. Also, feel free to evaluate their current implementation of this logic: https://github.com/citerus/dddsample-core/blob/master/src/main/java/com/pathfinder/internal/GraphTraversalServiceImpl.java. |
Correct. Let's kindly leave these alone. There is far more important work for us to do. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please address and consider the comments above.
I have followed up and opened a PR there, the project seems to be active so will update here on any progress. As for the implementation, there is no change in the logic the only difference being that instead of adding first leg and last leg for the candidate itinerary we add them inside the for loop itself.
I did some tests manually and it seems to work fine, for unit tests there is an ExternalRoutingServiceTest which contains
which seems to test this but is not in use and needs to be completed. Maybe this could be a part of #6 ? I'll make the changes requested meanwhile. |
OK. Just make the changes please and I will merge and test a bit myself. Yes, the unit tests need help. |
@m-reza-rahman , The maintainers for the original dddsample project have approved above changes too! It is passing their set of unit tests so hopefully there shouldn't be any worries of unknown defects creeping in. |
The existing findShortestPath() implementation for GraphTraversalService is cumbersome
and hard to read, hence it can be refactored and implemented in a simpler and more efficient manner.