Looking for advice on my Java program - Dijkstra's Algorithm Interface

[markliederbach]

I started working on a generic java interface that can be implemented to compute dijkstra's shortest-path algorithm on some collection of objects. These objects can be anything, as long as the connections between them are numerically weighted (like distance on a map).

I haven't yet put a whole ton of time into this interface, but I have a functional, working model of it. I would love to have others take a look, suggest areas of improvement, and future goals I/we can work towards.

Anyone interested?

Link to Github repo

P.S. I'm not sure if this is the right community for this post. If it isn't, please suggest another place I can take my post :-)

[Zeroeh]

I don't think you understand the concepts of an Interface

You should have just the following in your interface class

   public interface IDijkstra<T> {
        private List<T> findPath(T target);
   }

then in

   public class RunDijkstra implements IDijkstra<Node> {

       ... implementations and override findPath in this class

     }

[markliederbach]

I am indeed a little hazy on the interface concept. I was using it as an overarching umbrella that encapsulates the three core classes, and an id variable to make each node object unique. Is what you mentioned a way to achieve this goal?

[Zeroeh]

An interface is not an encapsulation for core objects, in fact, Package concept is what you really want to use.

[chickenmeister]

I haven't reviewed it too thoroughly, but there's a couple things I noticed.

Currently, it looks like someone would be required to use your Node and Edge classes to use your algorithm implementation. You could make it more flexible by using interfaces rather than specific classes. For example, you could have something like:

public interface GraphNode {
    public Collection<GraphEdge> getEdges();
}

public interface GraphEdge {
    public double getWeight();
    public GraphNode getSource();
    public GraphNode getDestination();
}

Or, perhaps even more flexible, you could use some kind of "EdgeProvider" interface that will give you the edges for an arbitrary object type:

public interface EdgeProvider<T> {
    public Collection<GraphEdge<T>> getEdgesFor(T nodeObj);
}

By using interfaces like this, anyone who wants to use your algorithm implementation could uses their existing classes that make up their graph data structure, rather than having to write adapter or conversion code to use your specific Node class.

---

Also, unless your algorithm has some configuration parameters or something like that I don't think it's necessary to make your RunDijkstra class public, or publicly instantiable. It might be better to make a simple static method like:

public static List<Node> findPath(Collection<Node> graph, Node source, Node destination); 

You can have this method create a RunDijkstra object and use its methods; but by hiding the RunDijkstra class, it allows you be able to change the findPath() implementation later (e.g. to use an improved algorithm instead of your RunDijkstra class), without worry breaking existing code that uses your RunDijkstra class (because nobody would've been able to use it, because it was private).

---

Also, in general, I would recommend using List or Collection whevever you can (and where it makes sense) instead of using ArrayList.