private versus protected

[BigWillyStyle42]

I know this has been brought up before, but I think it needs to be looked at again.

It is almost impossible to properly extend any class in JFreeChart simply because all the members are private along with several of the methods. If you want to extend TaskSeriesCollection you're better off starting from scratch since the two members, keys and data, are both private and you can't access them.

I wanted to be able to sort the column keys in a TaskSeriesCollection for display purposes and really can't control the order in which the data is added. So if you look at the code it could be solved by adding a call to Collections.sort( List ) in the refreshKeys method, which is of course private. Sure I could override the seriesChanged() method that calls refreshKeys and then override refreshKeys() as well, but I don't have any access to the 'keys' member so I'd never be dealing with the same list. Well then you could go create your own list of keys and then override every method that deals with keys, until you run into refreshKeys() at which point you'd realize that you also need a reference to the 'data' member that you also cannot get.

Every time I try to add functionality to any portion of JFreeChart it's always the same. I had similar frustrations trying to extend the Number & Date axes last year. You have to understand that if you want people to use this framework, and to extend it, and make it more useful for themselves, then you need to allow them to do so. By making all the members private and certain key methods private as well you're causing developers a world of pain.

[uvoigt]

I agree!
It is ok to make the fields private but their access methods should be protected!

[doofusLARGE]

Why don't you just change them? You could either change the private members and methods to protected in TaskSeriesCollection.java, or you could simply incorporate the changes your talking about right into the class itself, without having to override or extend anything.

[wwwclaes]

Agreed. As it is now, I have changed a lot of private variables and methods to protected to be able to extend them - and these changes need to be reapplied each time I upgrade JFreeChart.

[Guest]

Why not just do a global replace... make everything private protected.

This would solve so many issues when customising the API.

We need to use stupid hacks (reflective access) to do this as we didnt want to hack the distribution.

Why would an API designed for customisation use private variables and methods so much???? Its insane for those of us who know enough about the system to change it.

[Taqua]

Well,
private variables are great - as this is the only way you can be sure about the value of these beasts. Having no or private accessor methods for them is surely no fun at all and should be considered a design mistake. Fill a bug report or send a patch to David and I'm quite sure he'll fix it (or give you a reason why a particular member should be completly private).

Have mo' fun,
said Thomas

[Guest]

When designing an api like jfree you can never be sure someone wont need to access the variable.

In our extensions we have had to use reflection which is horrible and slow to do things. Others we havent been able to (override private methods etc).