Private methods can't be overridden?
in [Java Help]
|
From: Mike Schilling on 19 Feb 2010 11:37 Arved Sandstrom wrote: > > Myself I can see the argument for private virtuals: you're making a > statement that you've got a default implementation but it's > overridable, and if you do override you have to completely customize > - no calling the base method. Or no default, if it's private, virtual, and abstract, of course.
From: Andreas Leitgeb on 19 Feb 2010 12:04 Roedy Green <see_website(a)mindprod.com.invalid> wrote: > In Java, "private" means nobody else should use or override this > method. Marginally connected ramblings: If class "Foo" with a private method foo() is actually statically nested in another class Test, then its private method can be called from the outer class. One could also place another class Bar into Test, that at first glimpse *appears* to override foo(), but even despite this Bar.foo() is able to call "itself" per super, it isn't really overriding it! ---snip Test.java--- public class Test { public static void main(String[] a) { System.out.println(new Foo().foo()); // -> 42 System.out.println(new Bar().foo()); // -> 54 System.out.println(new Bar().bar()); // -> -42 } static class Foo { private int foo() { return 42; } public int bar() { return -foo(); } } static class Bar extends Foo { // @Override // compile error! (cannot be fooled) public int foo() { return super.foo() + 12; } } } ---snip Test.java---
From: Peter Duniho on 19 Feb 2010 12:43 Mike Schilling wrote: > Peter Duniho wrote: >> Mike Schilling wrote: >>> As I said in the part you snipped, it isn't a general rule. >> Then it seems to me that you aren't actually responding to the >> original poster's question, which was specifically about a general >> rule applied to virtual methods in C++. > > To quote: > >>>> I heard from people that do C++ that it is a good idea to make virtual >>>> methods private and public functions non-virtual >>>> (non-virtual-interface). > > That is, the OP was reporting something he'd heard about, not a practice > he'd followed or studied in detail. I've never heard of such a blanket rule > for C++. (I haven't coded in C++ for a while, but I did so almost > exclusively for about 6 years.) Have you? Has anyone? No. But that was my point in the first place. That's why I didn't understand you replying to my point, claiming that the pattern you described explained the statement that OP had heard about. I still think that whatever the OP is saying he had hard about, is either a misinterpretation on his part, or plain bad advice on the part of his source, whatever that might be. Pete
From: Mike Schilling on 19 Feb 2010 12:48 Peter Duniho wrote: > > I still think that whatever the OP is saying he had hard about, is > either a misinterpretation on his part, A misinterpretation of what? Perhaps a well-known pattern that uses private virtual methods. > or plain bad advice on the > part of his source, whatever that might be.
From: Peter Duniho on 19 Feb 2010 13:26
Mike Schilling wrote: > Peter Duniho wrote: > >> I still think that whatever the OP is saying he had hard about, is >> either a misinterpretation on his part, > > A misinterpretation of what? Perhaps a well-known pattern that uses private > virtual methods. It could be _anything_. There's no justification for concluding it's a misinterpretation of any particular thing. For all we know, the OP simply dreamed it, and then woke up the next day thinking he'd actually heard it from a reliable source. Of course, as it happens, the OP has followed up and pointed to the reference from which he took the advice. And note that while the general shape of the pattern you mention is included as part of the argument, that pattern is not in and of itself the justification given for the advice. The author the OP is referencing on the issue makes some good points IMHO. But in the end, I think those points are undermined significantly by the large body of work that already exists that doesn't follow the advice and yet which still works quite well. Pete |