Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!us.feeder.erje.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Accessibility of suBclass-fields from suPERclass (reflection) Date: Sat, 16 Aug 2014 09:47:15 -0400 Organization: A noiseless patient Spider Lines: 40 Message-ID: References: <53eecf6a$0$300$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 16 Aug 2014 13:47:20 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="bd4e1cba8d8592bec5d5ed9e4537fbfd"; logging-data="30147"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX195Xpwg4B56nO4559h6g6cG" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: Cancel-Lock: sha1:9tG+QPIoQhj4vr30BZ34ErIorOI= Xref: csiph.com comp.lang.java.programmer:29697 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