Sorry for the impolite subject.
I'm thinking if bertrand Meyer who said: "avoid inhertiance". When I have a look at the DataSet inheritence tree I understand him.
Have a look at the DataSet interface: The only methods it provides is registering and unregistering listeners, which as you will admit not the thing one firstly thinks of when thinking about a dataset. But this is exactly a problem, because it is not easy to serialize a dataset which woud be very useful, because you would have to serialize all listeners which of course might be problematic.
I think the registering of listeners should be in another interface which can than be implemented by an DataSet implementation optionally. This would be better design and a little bit directing to aspect oriented programming (aspect: event enabled, or so).
I suggest to redesign the dataset hierachy, but I think this is always a problem in a wide spread system.
So making a DataSet serializable should be outsourced to a Marshaler/Unmarshaler. I will implement this thing and send it you.
Wepper
BAd Design of interface DataSet
-
David Gilbert
Re: BAd Design of interface DataSet
Hi Wepper,
I agree.
My suggestion is to change the name of the Dataset interface to DynamicDataset (static datasets don't generate change events) and then remove the 'extends Dataset' from the PieDataset, MeterDataset and SeriesDataset interfaces. Then classes that implement any of the dataset interfaces can optionally implement DynamicDataset (it would be a requirement if the data can be changed, otherwise the chart has no way to know when it needs to redraw).
There would be some minor changes required elsewhere, but I think the impact on applications using JFreeChart would be minimal (certainly not as bad as changing the data access methods, which I would *like* to do but can't because it would break too many things).
Regards,
DG.
I agree.
My suggestion is to change the name of the Dataset interface to DynamicDataset (static datasets don't generate change events) and then remove the 'extends Dataset' from the PieDataset, MeterDataset and SeriesDataset interfaces. Then classes that implement any of the dataset interfaces can optionally implement DynamicDataset (it would be a requirement if the data can be changed, otherwise the chart has no way to know when it needs to redraw).
There would be some minor changes required elsewhere, but I think the impact on applications using JFreeChart would be minimal (certainly not as bad as changing the data access methods, which I would *like* to do but can't because it would break too many things).
Regards,
DG.
-
FritzWepper
Great Idea
Hi David,
I think this a very good first step. Following Fowler it is a little refactoring, which has little impact on other parts depending.
Many of refactoring could lead to a better design without having to redesign huge parts of depending packages.
So what about the serializing, which was the reason for my suggestions. If the listeners are optional inside of the Dataset hierarchy it should be no problem to let Dataset inherit Serializable.
Background: I'm working on a chart tag library based on JFreeChart (I'm not happy with the old one) and need to put Dataset into a pageContext. For that they need to be serializable.
When I'm finished, I will give it back to the community in LGPL'd form.
Greetings
Wepper
I think this a very good first step. Following Fowler it is a little refactoring, which has little impact on other parts depending.
Many of refactoring could lead to a better design without having to redesign huge parts of depending packages.
So what about the serializing, which was the reason for my suggestions. If the listeners are optional inside of the Dataset hierarchy it should be no problem to let Dataset inherit Serializable.
Background: I'm working on a chart tag library based on JFreeChart (I'm not happy with the old one) and need to put Dataset into a pageContext. For that they need to be serializable.
When I'm finished, I will give it back to the community in LGPL'd form.
Greetings
Wepper