Private methods can't be overridden?
in [Java Help]
|
From: Eric Sosman on 18 Feb 2010 15:59 On 2/18/2010 2:43 PM, Johannes Schaub (litb) wrote: > I heard today that in Java you cannot override private methods. [...] Right. Something that is `private' to a class is *not* part of the class' API. It's not even visible to other classes, the idea being that there is no way another class can possibly depend on it. A consequence: If it's `private', you can change it or even delete it, and no other class will be affected at all. If a subclass could inherit (and possibly override) a `private' method, the method would no longer be private in any meaningful sense. The superclass would not be free to change the method's signature -- adding a `throws', for example -- without that change propagating to the subclasses. The method *would* therefore be part of the superclass' API, exactly the opposite of what `private' means. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Johannes Schaub (litb) on 18 Feb 2010 16:06 Eric Sosman wrote: > On 2/18/2010 2:43 PM, Johannes Schaub (litb) wrote: >> I heard today that in Java you cannot override private methods. [...] > > Right. Something that is `private' to a class is *not* > part of the class' API. It's not even visible to other classes, > the idea being that there is no way another class can possibly > depend on it. A consequence: If it's `private', you can change > it or even delete it, and no other class will be affected at all. > > If a subclass could inherit (and possibly override) a `private' > method, the method would no longer be private in any meaningful > sense. The superclass would not be free to change the method's > signature -- adding a `throws', for example -- without that change > propagating to the subclasses. The method *would* therefore be > part of the superclass' API, exactly the opposite of what `private' > means. > Oh, i see now. I think this makes sense. Thanks for the nice explanation!
From: Lew on 18 Feb 2010 16:09 Johannes Schaub (litb) wrote: >>> I heard today that in Java you cannot override private methods. I'm >>> wondering about this snippet: >>> >>> class Printer { >>> public void print() { >>> preparePrint(); >>> doPrint(); >>> finalizePrint(); >>> } >>> >>> private abstract void doPrint(); Lew wrote: >> This is an illegal statement. Did you try to compile it? Johannes Schaub (litb) wrote: > I'm sorry. My whole question is about why it *doesn't* compile. I feel like > you rushed over my question, call me a "troll" and go on giving me tutorials > that do not seem to answer my question and slapping me for mentioning C++. Huh? I never called you anything, much less a "troll". I gave objective answers to your questions as asked, and asked for objective information relevant to your stated problem. I am so sorry you didn't find my answers useful. Do bear in mind that they were accurate and comprehensive. FWIW, one of the defining characteristics of a troll (which I am most definitely not calling you) is to take as an insult an answer which is objective and literally relevant to the question. Lew wrote: >> Since a 'private' member cannot be inherited, and an 'abstract' method by >> definition must be inherited, the combination 'private abstract' is >> illegal. Johannes Schaub (litb) wrote: > I was told so, which motivated this question. > >>> }; >>> >>> class LaserPrinter extends Printer { >>> private void doPrint() { Lew wrote: >> Since 'private' methods are not inherited, this is a completely separate >> method from the superclass's (illegal as written) 'private' method of the >> same signature. >> >> Because 'private' methods are not inherited, the superclass 'print()' >> method will call only the superclass 'doPrint()' and will not >> polymorphically invoke that of the subclass. Johannes Schaub (litb) wrote: > I'm aware of that. But i'm [sic] wondering for the reason? One can only speculate. However, the observed utility is that 'private' members are exactly that, members that are owned only by the defining class, not neighbors in the same package, not children, and not foreign classes. Since there are four access levels in Java, one of the other three will certainly do what you are trying to do. So leave 'private' for those things that really must be, well, private. >>> // print stuff >>> } >>> }; >>> >>> I wonder why i [sic] can't write it like this. Lew wrote: >> Because the purpose of 'private' is to prevent just that. Johannes Schaub (litb) wrote: > Why should it prevent that? Because if it didn't, the member would be exposed, not private. > It seems like a good thing to have only a method > that can be implemented, and that is not exposed for calls at the same time. For that you have 'protected' and package-private. Johannes Schaub (litb) wrote: >>> What is the reason Java doesn't follow this path? >> Because Java is its own language with its own rules. It isn't C++, it Lew wrote: >> isn't BASIC, and it isn't FORTRAN. Johannes Schaub (litb) wrote: > That's not a good answer, i'm [sic] sorry. I'm sorry, too, because it is the answer, whether you like it or not. -- Lew
From: Lew on 18 Feb 2010 16:11 Johannes Schaub (litb) wrote: > Oh, i [sic] see now. I think this makes sense. Thanks for the nice explanation! You're welcome. -- Lew
From: Roedy Green on 18 Feb 2010 17:48
On Thu, 18 Feb 2010 21:18:17 +0100, "Johannes Schaub (litb)" <schaub-johannes(a)web.de> wrote, quoted or indirectly quoted someone who said : >I'm sorry. My whole question is about why it *doesn't* compile. I feel like >you rushed over my question, call me a "troll" and go on giving me tutorials >that do not seem to answer my question and slapping me for mentioning C++. Don't take it personally. Lew does that to everyone. The thinks everyone is as smart and energetic as he. Think of him as like House. -- Roedy Green Canadian Mind Products http://mindprod.com When a newbie asks for help tracking a bug in a code snippet, the problem is usually is the code he did not post, hence the value of an SSCCE. see http://mindprod.com/jgloss/sscce.html |