Creating a standard graph builder using OOP and design patterns

Question

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

UPDATE my complete idea

I've been given this a lot of thought since I started this post, and I finally got the idea that I think this is a solid use of the Builder pattern. I want you guys what you think and what problems you think I might run into. First let me explain the whole idea:

My company needs some kind of standard schedule with a connected table, which they can use for all their programs (this will give the programs the feeling that they are all the same (they are). Since most of these diagrams are the same, I thought I could ease the pain of creating a new diagram every time you need to make a new program or place the diagram somewhere else.

My company uses three different charts:

• banded
• Linechart
• Piechart

When creating these diagrams, there are several unknown variables.

• Chart Series Name: This is the name that will be displayed, and it is different from each fragment of a line / bar / pie

• Period: chart data is taken from a time period, either a day or a week (every day on Monday, Tuesday, Wednesday, etc.) per month (January, February, March, April, etc.) or even the time of day. (20:00 pm, etc.).

• Chart Type: Of course, the difference is what type of chart the user wants to see.

The last, but no less important difference between creating a chart lies inside Piechart, pieChart is the only chart in Javafx that is not created from a series, but is created from the Observable list, so pieChartBuilder should use and insert data differently than others.

The picture above is not a UML diagram, it is a demonstration of how I plan for my new program to behave and customize the design template, here is a glimpse of my thoughts:

• GUI: at first, Gui is always separated from the real logic, I have no plans to require anything from the GUI, except that it must be created in JavaFx and must have an instance of the Director class.

• Director: The Director class is the place where all the action takes place. First, the client calls the director what type of chart he wants to receive, what period of time he wants to receive data, and maybe what data he wants to see. The client also sets the period of time in which he wants to see the data (day, week, month, year, etc.).

The director then takes all this data and classifies his instance of the statistics class, requesting a class for the data that the director can then pass to the chart builder.

• Statistics: the statistics class then checks whether it already contains data, and if not, the class for the list of objects in the database:

• Database: the database is fairly straightforward for the data for the period of time that the client sends (either per day, week, month, year) creates the object (s), adding them to the list and returning it to the statistics class.

• (back to) the statistics class, then the object data is calculated and returned to the director.

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

This is my idea. I would like you to comment on this. Thanks for reading, and I will look forward to reading all of your answers.

Answer 1

The most common design patterns for graphic tasks are Decorator (often with a “free” interface ), Prototype / Clone, and Visitor. It will be useful.

Decorator : if you want to gradually add attributes to the object. For instance:

 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 : so that you can duplicate any object (copy / paste functions). This is basically a Clonable interface.

Visitor : if you want to add functionality to objects without adding code to the actual object. Say if your application is some kind of script. See this post for an example: Visitor Template

Now, to talk about your specific solutions:

Decorator seems to be a good way to implement your first solution. Alternative Template method or some composition ("combine a common graphic box with a data object").

For your second solution, Factory seems appropriate.

I can’t say which is better. It depends on your local circumstances. All implementations have pros and cons, and the trick is to choose the one where the pros outweigh the cons.

Updates for the updated question:

ChartBuilder: This is probably the "Builder" design template . This dp is a representation or provision of an abstract description / product, such as a document description or a dataset in different ways.

Director: This is a project of patter Mediator . Or Facade , depending on the intention. Facade, if you "hide" a ball of shitty outdated code, "Mediator", if you coordinate the interaction of several more modern classes. There is a lot of gray area. If the director also interacts with the graphical interface (resize, hide, etc.), he is definitely an intermediary.

In general, your structure is a model / viewer / controller. The director acts as a controller, statistics acts as a model, chartBuilder acts as a viewer.

It is not uncommon that several design patterns overlap, as with a controller as an intermediary.

You can be happier if you implement all this as a request / response, using the Observer design template to respond, and not as direct calls with return values. This is more flexible, and you can hide the latency / calculation / database search in the stream better.

You can use Composite for chartBuilder. If you want to display several types of data at the same time, not just one.

Answer 2

Take a look at EyeSee and implement java implementation