Call Overriden Method from Constructor
class Super{
Super(){
System.out.println("In Super constructor");
test();
}
void test(){
System.out.println("In Super.test()");
}
}
class Subextends Super{
Sub(){
System.out.println("In Sub constructor");
}
void test(){// overrides test() in Super
System.out.println("In Sub.test()");
}
}
Output - In Super Constructor
In Sub.test()
In Sub Constructor
Suppose i create a subclass object, so at first superclass's constructor will be called, but then how can it call subclass's test, since the object for the derived class and method's implementation has not been allocated memory?
[1324 byte] By [
enterneoa] at [2007-11-27 8:56:14]
I think the subclass may have actually had space on the heap at that point.
But that's a moot point anyway. The methods are associated with instances, but the methods don't reside in the instances.
And either way -- it's a bad practice for constructors to call non-final methods, for exactly this reason. It makes the constructors unpredictable.
I believe I read somewhere that every object's constructor calls the super's no-parameter constructor if you do not tell it to explicitly call a constructor from the super method first.
class Super {
Super() {
// do stuff
}
}
class Sub extends Super {
Sub() {
Super() // happens even if not present if you don't specify a constructor to reference
// do stuff
}
}
So, in this example, I'd guess that there is no "Super" object being created.. Only a Sub object .. just simply that it runs the Super constructor first.
I might be wrong on that -- but I'm pretty sure that's what's going on.
JJCoolB has a good point. It can't really call the "test" method in Super because no "Super" object exists.
You can call the subclass' method. There's only one object. It is both a Super and a Sub.
HOWEVER, this is generally a very bad idea. It's possible for the subclass' override of that method to rely on stuff in the superclass that hasn't been initialized yet (because the basic premise is that the subclass assumes the superclass is in a valid state by the time anything is done with it), and it's also possible for it to rely on stuff in the subclass that assumes that subclass portion of that object has been properly initialized.
Unless you're very careful, document stuff very thoroughly, make the classes package private, etc., there's a good chance something will get royally screwed up.
jverda at 2007-7-12 21:18:45 >
> JJCoolB has a good point. It can't really call the> "test" method in Super because no "Super" object> exists.Bull.A single object exists. It is both a Super and a Sub. If Sub hadn't overridden test(), then Super's test() would have been called.
jverda at 2007-7-12 21:18:45 >
> I think the subclass may have actually had space on
> the heap at that point.
>
> But that's a moot point anyway. The methods are
> associated with instances, but the methods don't
> reside in the instances.
>
> And either way -- it's a bad practice for
> constructors to call non-final methods, for exactly
> this reason. It makes the constructors unpredictable.
> But that's a moot point anyway. The methods are
> associated with instances, but the methods don't
> reside in the instances.
Exactly. Although the method requires an instance upon which to be called, the method definition is not part of the instance--it's part of the class.
> And either way -- it's a bad practice for
> constructors to call non-final methods, for exactly
> this reason. It makes the constructors unpredictable.
Hear, hear!
jverda at 2007-7-12 21:18:45 >
>A single object exists. It is both a Super and a Sub. If Sub hadn't overridden
>test(), then Super's test() would have been called.
Right. My point was that no instance of Super existed that wasn't also an instance of a subclass that happened to overwrite the test() method.
> You can call the subclass' method. There's only one
> object. It is both a Super and a Sub.
>
> HOWEVER, this is generally a very bad
> idea. It's possible for the subclass' override of
> that method to rely on stuff in the superclass that
> hasn't been initialized yet (because the basic
> premise is that the subclass assumes the superclass
> is in a valid state by the time anything is done with
> it), and it's also possible for it to rely on stuff
> in the subclass that assumes that subclass portion of
> that object has been properly initialized.
>
> Unless you're very careful, document stuff very
> thoroughly, make the classes package private, etc.,
> there's a good chance something will get royally
> screwed up.
I have a question, then, because I have made many constructors that call other methods (example: initBoard() ) .... but I've always made those methods private (not protected or public). Would this be a safe practice? Or not? Would it be better if I used the this keyword for calling those methods? I'm assuming the "safe" way to do it would be to have the methods final, as mentioned above, but does private achieve the same result in this situation?
> I have a question, then, because I have made many
> constructors that call other methods (example:
> initBoard() ) .... but I've always made those methods
> private (not protected or public).
If the method is private, it can't be overridden, so it's not a problem.
> Would this be a
> safe practice? Or not? Would it be better if I used
> the this keyword for calling those methods?
Using this won't make a difference. It's implied anyway. Calling foo() is the same as calling this.foo(), regardless of whether the method is private, public, etc.
jverda at 2007-7-12 21:18:45 >
but, in terms of overridden methods, if I had...
class Super {
Super() {
this.foo();
}
public void foo() {
System.out.println("Super");
}
}
class Sub extends Super {
Sub() {
Super();
}
public void foo() {
System.out.println("Sub");
}
}
Doesn't the this keyword in the super guarantee that it calls the super's foo method? That's how I thought it worked, at least.
> but, in terms of overridden methods, if I had......> Doesn't the this keyword in the super> guarantee that it calls the super's foo method?> That's how I thought it worked, at least.Try it and see.
jverda at 2007-7-12 21:18:45 >
