I am doing a project on Graph Theory and am implementing some graph algorithms.
I would like to separate
- the Algorithm’s code (such as BFS,DFS…),
- the Graph handling code(such as Graph class itself, Edges and vertices handling..etc), and
- the GUI related code
I have 2 questions related to the design of the application:
-
Should I use a separate package for each? Also, anything anyone can add about connecting and making those parts co-operate would be helpful.
-
What design pattern should I use for the Algorithms code? Should it be a static class, a singleton, or any other suggestion?
There is no general answer. The decision depends on whether and how you are planning on reusing the system you are developping.
As you specified, using well known design patters is a good idea. I don’t know your architectural goals, but I can recommend the following general guidelines:
Design the “model” (data structure) in its own package. This layer should only include “model”, and “state” representation of your system: graph, vertex, orientation, weights, etc. This layer most likely should also contain model maintenance logic (Add a node to the graph, get nodes, get vertex, create vertices, add weight, etc) Take a look at the structural patterns (Composite, Facade, etc) and see if any of them could be applied to your model.
Implement the algorithms in a separate layer. Most of the time, making these components “stateless” is a good idea (static functions performing operations on the model). Take a look at the behavioral patterns (Visitor, Chain of Responsibility, Iterator, Interpreter, Command, etc. ), and see if any of them could be applied.
Use the Observer design pattern to design your “rendering” (displaying, visualizing) layer. This pattern allows you to decouple the observed(model) and the view, and eventually provide several types of views for the same model.
As I said, there is no general solutions. These are just some ideas with the goal of implementing decoupled and easily maintainable and reusable software.