Re: Accessibility of suBclass-fields from suPERclass (reflection)
On 8/16/2014 8:37 AM, Chris Uppal wrote:
Robert Klemme wrote:
If I understand your issue correctly: this is not about security but
about design principles. Dependency always goes up the inheritance
chain - not downwards. Meaning, all subclasses have knowledge about
their superclasses but not vice versa.
Agreed, though I think "always" is a little strong. It is possible to have
clusters of co-designed classes where the superclass "knows about" it's
subclasses. For instance the superclass could act as a factory for instances
of its sublclasses, where the subclasses (what they are and how many of them
there are, etc) is hidden from the consumer code.
(In such cases I'd often like to be able to declare the superclass as "final
except that it can have subclasses in the same package")
Make the superclass constructor package-private, and you'll get a
fairly good approximation to "package-final."
But back up a bit: What's the nature of the "knows about" relation
between superclass and subclass? In ordinary Java, "knows about" is
handled by requiring the "known-about" class to implement an interface,
and there's no need for the superclass (or any other client) to know
how the interface is implemented. Why snoop around with reflection?
Okay, maybe the "knows about" is in support of Version 2.0 of the
Parsifal Plugin Protocol, and isn't really related to the external
purpose of the subclass: You don't want to expose the PPP2 methods to
clients, because they'd abuse them and/or get into trouble when you
upgrade to PPP3. In that sort of case one can implement the interface
in an inner class of the subclass, and provide that inner class to
the superclass for its private use. (I'd have to think a bit about
how to do so cleanly; it's tempting to hand the accessor inner class
instance to the superclass' constructor, but that's probably a
premature `this' leakage. Maybe the superclass could expose a
`protected void setAccessor(InnerClassInterface accessor)' method?)
--
esosman@comcast-dot-net.invalid