Improve Use of Interfaces

A discussion forum for JFreeChart (a 2D chart library for the Java platform).
Locked
tcole6

Improve Use of Interfaces

Post by tcole6 » Thu Feb 16, 2006 3:59 pm

I've noticed that there are spots in JFreeChart where improved use of interfaces and/or abstract classes would make life WAY easier. For example:

AFAIK all the URL generators in the org.jfree.chart.urls package contain a generateURL method. Each of these work the same, with the exception of the dataset needed.

Now these datasets do not inherit a common interface nor do they extend some common class.

What this leads to is a bit of a mess. IF the datasets all inherited from a common interface or abstract class, all the generators could inherit from a single interface that would only as for this uppermost "dataset" object. Each specific generator would then be responsible for casting to the appropriate dataset, blah blah blah.

If this were in place (we had a common top level URLGenerator interface and Dataset interface) and someone wanted to create a class that opened URLs into a new window, life could be as easy as:

Code: Select all

public class NewWindowURLGenerator implements SomeGenerateURLSuperInterface {

  private SomeGenerateURLSuperInterface master;
  private String windowName;

  public NewWindowURLGenerator(SomeGenerateURLSuperInterface master, String windowName) {
    this.master = master;
    this.windowName = windowName;
  }

  public String generateURL(SomeDatasetSuperInterface data, int series, int category) {
    String url = master.generateURL(data, series, category);
    return "javascript:window.open('" + url + "', '" + windowName + "');";
  }
}
Now wouldn't that be nice?

I've not dug that deeply into (to be totally honest). However I'm sure there are a lot more cases of this type of thing.

Am I missing something horribly obvious that makes this impossible?

dougclayton
Posts: 6
Joined: Tue Feb 14, 2006 10:56 pm

Post by dougclayton » Thu Feb 16, 2006 6:53 pm

The problem is, as I see it, that the datasets cannot all share a common interface by necessity. For instance, if you have category data, the notion of "x" and "y" do not make sense. If you have x-y data, the domain is numerical, not categorical.

Consider the dataset interface I am most familiar with, XYDataset, which returns a numerical y-value for a numerical x-value plus an integral series index. You can't make an interface that is common to that and other datasets that don't deal in such terms. Furthermore, your URL generator has to know what type of dataset it is working with, because (in the case of the dataset above) it has to know which series index to supply, for instance.

In most cases in JFreeChart, I'm not sure you could get more abstract than they have. You certainly can't abstract away differences in the various dataset interfaces. That's why the generic Dataset interface does not specify methods for getting or adding data.

mhilpert
Posts: 497
Joined: Wed Apr 02, 2003 1:57 pm
Location: Germany

Post by mhilpert » Fri Feb 17, 2006 9:23 am

I agree with tcole6. I had such a discussion with David (author of JFreeChart) about 1 year ago. In the end I wrote my own wrapper around JFreeChart that does offers a more user friendlier API (at least in my opinion). Many classes are just clutered without a clean object model (logic inheritance, usage of interfaces). The CategoryDataset is a good example: we _are_ using the Category dataset for X/Y charts. The category is nothing alse then a X/Y chart. The "categories" are the x values and the "ranges" are the y values. I mapped those names all to X/Y names and we have a lot of charts displaying such X/Y charts and the normal user doesn't see if it's a CategoryDataset, a XYDataset or anything else. I guess David developed the library bottom up instead of top down, meaning: he played with a few charts, started with the library and slowly more charts were added. And instead of changing the design top-down to integrate the new tyes of charts, they were integrated with special cases - unfortunately sometimes without a general super class or at least interface.

Well, JFreeChart is quite big and has grown over years, so it's not possible to redesign everything (perhaps David is doing this for 2.0 version with 3D all over the place ;-) ). But it should be possible to hear the app developers using JFreeChart to simplify the API whereever it's possible.
Java 11, JFreeChart 1.0.15, JFreeSVG 4.0

Locked