Having worked in a module system with package-level module-membership, I can't say I feel a burning need for class-level membership (much less member). The one argument I've seen is to enable unit-tests to have special access to otherwise non-public class members. There are ways to solve that with package-granularity (some are ugly, but doable if your paranoid). But moreover, while it is somewhat common for external code to call a method such as your setProperties() method above, and that shouldn't be polluting the API, it's much less common for code in the same package in malicious or misbehaving ways, for the social reason it is much more likely to be maintained by the same people (and with the ability to have hidden packages, the probability of having packages with massive numbers of unrelated classes goes down because package-privacy is no longer the only means of hiding implementation). I worry about issues such as the public setProperties() example as well, which can be abused, and avoid this sort of thing. I just don't worry about classes from the same package abusing something package-private that's there for unit tests - it's just not probable enough.
<p/>
I'd say that for sheer reduction of the number of things I need to hold in my mind when developing, I'd much rather just know that the packages I can see are a subset of what exists.
<p/>
I could be grossly misunderstanding things here, and I'm definitely surmising a few things, so feel free to correct me.
<p/>
-Tim |
java.net RSS Feeds
