Creating a standard graph builder using OOP and Design Patterns

Question

This is an example of my firms costum made chart with connected table.

UPDATE my full idea

i have been given this alot of thinking since i started this post and i have finally come up with an idea that i think is solid using the Builder pattern i want to you guys what you think and what issues you think that i might run into. First let me explain the full idea:

My Company need some sort of Standard graph with a connected table that they can use for all of their programs (This will give the programs a feeling that they are all alike (which they are)) Since most of these charts are alike i thought i could easy the pain of creating a new chart every time you have to make a new program or have to place the chart somewhere else.

My Company use three diffrent charts primarily:

• Barchart
• LineChart
• PieChart

When creating these charts there are a few unknown variables.

• Name of the chart series: This is the name that will be display and this differs from every line/bar/ pie slice

• Period: Chart data is taken from a period of time, either a day or a week (every day Monday, Tuesday, Wednesday etc) a month (Jan,Feb,mar,April etc) or even time of day.(8pm,9pm etc).

• Type of chart: of-course a difference is what type of chart the user wants to see.

Last but not least the only difference between the chart creating lies within the Piechart, the pieChart is the only chart in Javafx that is not created from series but is created from an Observable list, so the pieChartBuilder has to use and insert the data in a different way than the others.

The picture above is Not an UML diagram it is a demonstration of how i plan my new program(s) to behave and adjust the design pattern, here is a walk through of what my thought are:

• GUI: First the Gui is always separated from the actual logic i have no plans of demanding anything from the GUI except that it has to created in JavaFx and it has to have an instance of the Director class.

• Director: The Director class is where all the action happens. First the client calls the director with what type of chart he wants to get, what period of time he wants data from and maybe what kind of data he wants to see. The client also sets the time period that he wishes to see the data in (day, week, month , year etc).

The Director then takes all of that data and class his instance of the statistic class asking the class for data that the director can then pass on the the Chart builder.

• Statistics: the statistics class then checks if it already contains data and if not it class for a list of object to the database:

• DataBase: The database is quite straight forward it class for the data in the time period that client has send on (either on a day, week, month, year basis) creates the object(s) add them to a list and return it to the statistics class.

• (back in the) statistic class the objects data are then calculated and returned to the director.

• (Back in the director) The director now calls the chartBuilder to build a chart of the type specified by the client with the timeframe (which is an array or an arraylist of time, This is an option the client can set in the director using Director.setStandardTime(time)) the builder then creates the chart and table with the data obtained from the Director. The client is then able to call ChartBuilder.getChart() and add that to his layout.

This is my idea. i Would love for you to comment on it. Thank you for reading and i will be looking forward to read all of your responses.

Answer 1

Take a look at EyeSee, and make a java implementation

Answer 2

The most common Design Patterns for graphics tasks are Decorator (often with a "fluent" interface), Prototype/Clone and Visitor. These will proably come in handy.

Decorator: For when you want to add attributes to your object incrementally. Such as:

final int radius = 100;
// With fluent interface
final Graphic boxedShadedCircle = new Circle(radius, 100, 100).shaded().boxed();
// Without fluent interface
final Graphic nonFLuentBoxedShadedCircle = new Boxed(new Shaded(new Circle(radius, 100, 100)));

Prototype/Clone: For when you want to be able to duplicate some object (copy/paste functionality). It's basically the interface Clonable.

Visitor: When you want to add functionality to objects without adding to the code in the actual object. Say, if your application is somehow scriptable. See this post for an example:Visitor pattern

Now to relate to your specific solutions:

It seems like Decorator would be a good way to implement your first solution proposal. Alternatively Template method or some sort of composition ("combine generic graph drawer with data object").

For your second solution, Factory seems appropriate.

I can't say which is best. It depends on your local circumstances. All implementations have pros and cons, and the trick is to pick the appropriate one where the pros outweigh the cons.

Updates for the updated question:

ChartBuilder: This should probably be design pattern "Builder". This dp is about representing or rendering an abstract description/product such as a document description or a data set in different ways.

Director: This is Design patter Mediator. Or Facade, depending on intent. Facade if you are "hiding away" a ball of crappy legacy code, Mediator if you are coordinating the interaction of several more modern classes. Lots of grey area here. If Director also handles interaction with the GUI (resize, hide etc) it's definitely Mediator.

Overall, your structure is model/viewer/controller. Director acts as controller, Statistics acts as model, chartBuilder acts as viewer.

It's not uncommon to have several design patterns overlap, as in having the controller act as mediator.

You may be happier if you implement the whole thing as request/response using design pattern Observer for the response, rather than as straight calls with return values. It's more flexible that way, and you can hide latency/calculation/database lookup in a thread better.

You may want to use Composite for chartBuilder. If you want to have several views on the data active at the same time, rather than just one.