Suggestions about interface: graph, directed and undirected graph

Question

Hello all,
I'm having some doubts about the right 'choice' of interfaces. I'm designing a little library for graphs and I was thinking about the difference between directed and undirected graphs, and how I should reflect this in the library. My apologies for my bad English.
There is a small, but elegant, difference between directed and undirected graphs. Therefor, I don't know if it's worth to distuingish this difference in interfaces or not. I'll explain the difference by example. Usually, you can ask a directed graph the following queries:
- all out-edges of a node + the total of such edges (outdegree)
- all in-edges of a node + indegree
- the successors of a node
- the predecessors of a node
The same questions can be asked to a undirected graph, but the in-edges and the out-edges of a node are equal, the successors and the predecessors are equal, etc... Thats basically the only difference between directed and undirected graphs.
I found some solutions to define graphs, directed graphs and undirected graphs by means of interfaces.
[1] one interface, duplicate methods, no tagging interfaces
public interface Graph {
    Set getOutEdges(Node node);
    int getOutDegree(Node node);
    Set getinEdges(Node node);
    int getinDegree(Node node);
    Set getSuccessors(Node node);
    Set getPredecessor(Node node);
    boolean isDirected(); // no tagging interface
}[2] one interface, duplicate methods, tagging interfaces
public interface Graph {
    Set getOutEdges(Node node);
    int getOutDegree(Node node);
    Set getinEdges(Node node);
    int getinDegree(Node node);
    Set getSuccessors(Node node);
    Set getPredecessor(Node node);
public DirectedGraph extends Graph { } // tagging interface
public UndirectedGraph extends Graph { } // tagging interface[3] three interfaces
public interface Graph {
public interface DirectedGraph extends Graph {
    Set getOutEdges(Node node);
    int getOutDegree(Node node);
    Set getinEdges(Node node);
    int getinDegree(Node node);
    Set getSuccessors(Node node);
    Set getPredecessor(Node node);
public interface UndirectedGraph extends Graph {
    Set getTouchingEdges(Node node);
    int getdegree(Node node);
    Set getNeighbors(Node node);
}In the first solution, you dont know at compile time whether a graph is directed or undirected. However, it is very elegant for algorithms, since a lot of algorithms work for directed and undirected graphs. The main disadvantage of this solution is that you have duplicate functions in case of of undirected graphs: getOutEdges and getInEdges return the same set, etc.
The difference between the first and the second solution is that the second solutions gives a way to detect whether a graph is directed or undirected at compile-time.
The third solution has two seperate interfaces. This is much logical, and you know the graphtype at compile-time. However, this approach might lead to bloated code, as the algoritms for undirected and directed graphs now have two graphtypes (this can ofcourse be fixed by itroducing some kind of decorator, which in fact simulates the first solution).
As I don't have much experience in design, I can't forsee any big problems or disadvantes of one of the approaches. Therefor, I would like to ask for your opinion. What approach is most common and best practice?
Thanks in advance.

Answer 1

I would tend to go with true inheritance for this case. There is a strong ISA relationship between a graph and uni-directional and bi-directional graphs. Programming to an interface (as in the Lyskov substitution principle) will give you a parallel heirachy of interfaces and implementations. This can become a problem if you start out not knowing what interface needs to be published, but in the case of graphs this should not be a problem. With a heirachy all the shared code can be written once. In this case the specialized code will just simplify calling more general code in the parent class.
If all your graphs fit into memory then the implemenation should not be a problem. I used to work with map data where the graph does not fit into memory. Then you have to be careful about your interface or you will be getting calls that cannot be properly optimized "behind the scenes". Another specialization is in game programming where nodes are not actually expanded until they are "arrived at". Then you have to keep information about what parts of the structure are fleshed out and which are provisional.