Protected fields in TreeCache

[brian.stansberry]

As part of the API cleanup for 2.0, what do people think about changing all the protected fields in TreeCache to private, or, if needed, package-protected? A protected field is really part of a class' public API. Since we're going to the effort of locking down all the API's, this seems like a good thing to lock down as well.

If any of these fields really need to be exposed to subclasses, we can do it through a protected setter/getter, which IMHO is a more controlled way of exposing something as part of the public API.

I realize we're doing things like using Cache and CacheSPI to isolate the "user API" from the internal one, but I think its also a good practice to limit the public API of the internal classes as much as possible.

[manik]

+1

Any specific bits as potential candidates?

[brian.stansberry]

I was basically thinking all of them; for anything used by PojoCache we could add a getter/setter. I think Ben is going to use delegation in PojoCache instead of subclassing, so maybe it's good to wait until he's done that so we don't add getter/setters for fields he won't need after his refactor.

This came up because I'm creating a StateTransferManager for JBCACHE-465 so Ben can do what he wants with a PojoCache-specific version. I was adding the field for it and didn't want to add another protected field :)

[ben.wang]

+1 here since we are moving to API/SPI model.

For PojoCache integration, I have refactored my code to use some delegation (from a sub-class of TreeCache). So next step is to use Cache implementation directly. There is an integration task for this in 2.0.

http://jira.jboss.com/jira/browse/JBCACHE-685

I think it is ok to go ahead now. I suspect there are only few in PojoTreeCache that needs changed (without looking at it first).

[galder.zamarreno]

+1 on removing any protected fields. They should all be private with getter/setters where necessary.