Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Accessibility of suBclass-fields from suPERclass (reflection) Date: Sun, 17 Aug 2014 13:19:52 +0200 Lines: 32 Message-ID: References: <53eecf6a$0$300$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net WspPSehmj6scN7fqDkCI1QUIj86fEjFkthh0TCvFZHX0eP0Qc= Cancel-Lock: sha1:T0smsW4GgxAL8O/Z1eHypcVfXa0= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:29705 On 16.08.2014 14:37, 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. Still then the superclass needs to know zero about subclass internals. Of course, as long as the subclasses are visible to the superclass it can use them like any other class (e.g. a separate factory class) could. But that's a rather weak dependency and has nothing to do with specifics of the interface or implementation of subclasses. > (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") I don't see the point. Actually it's contradicting: a final class does not have subclasses - nowhere. Eric provided a good means how to prevent subclassing in other places of the code where you do not want to allow it. Cheers robert