Re: how to access the overrided fields o# Java - 爪哇娇娃
xt
1 楼
First, it is called "Overridden";
Second, you can use super.b to access the one in super class,
provided that variable has appropriate access level (protected
or public).
First, it is called "Overridden";
Second, you can use super.b to access the one in super class,
provided that variable has appropriate access level (protected
or public).
n*r
2 楼
you mean super.b ?
b is the instance variable
anyway, I will try.
【在 xt 的大作中提到】
:
: First, it is called "Overridden";
: Second, you can use super.b to access the one in super class,
: provided that variable has appropriate access level (protected
: or public).
b is the instance variable
anyway, I will try.
【在 xt 的大作中提到】
:
: First, it is called "Overridden";
: Second, you can use super.b to access the one in super class,
: provided that variable has appropriate access level (protected
: or public).
n*r
3 楼
it doesn't work
In case you didn't understand my question, please re-read it again.
I want to access it outside the B's method body.I know use super to
access it inside B's method body
【在 n*****r 的大作中提到】
: you mean super.b ?
: b is the instance variable
: anyway, I will try.
c*t
4 楼
dynamically cast class B to A, then you can use t
【在 xt 的大作中提到】
:
: First, it is called "Overridden";
: Second, you can use super.b to access the one in super class,
: provided that variable has appropriate access level (protected
: or public).
【在 xt 的大作中提到】
:
: First, it is called "Overridden";
: Second, you can use super.b to access the one in super class,
: provided that variable has appropriate access level (protected
: or public).
n*r
5 楼
you mean upcast by using "(A)b"?
I don't think it will work because upcast in java is just a check
【在 c**t 的大作中提到】
: dynamically cast class B to A, then you can use t
I don't think it will work because upcast in java is just a check
【在 c**t 的大作中提到】
: dynamically cast class B to A, then you can use t
c*y
6 楼
1) Define a variable with the same name in a derived class will "hide" the
variable of the same name in the base class, but it's not called "overidding".
You only override a method, not a variable.
2) Both C++ and Java use static typing, which means the variables are resolved
at compile time. So if if you directly cast your derived class into a base
class, and try to refer to the variable, then the one defined in the base
class will be used. Ex:
class base{
public String value = "Base";
}
class
【在 n*****r 的大作中提到】
: you mean upcast by using "(A)b"?
: I don't think it will work because upcast in java is just a check
variable of the same name in the base class, but it's not called "overidding".
You only override a method, not a variable.
2) Both C++ and Java use static typing, which means the variables are resolved
at compile time. So if if you directly cast your derived class into a base
class, and try to refer to the variable, then the one defined in the base
class will be used. Ex:
class base{
public String value = "Base";
}
class
【在 n*****r 的大作中提到】
: you mean upcast by using "(A)b"?
: I don't think it will work because upcast in java is just a check
n*r
7 楼
interesting
so in the following example:
public class Base {
private String field ="base";
public String toString(){
return field;
}
class Derived {
private String field ="derived";
public String toString(){ //method X begin
return field; //method X
} //method X end
public static void main(String[]args){
Derived d=new Derived();
System.out.println(d);//output
}
Thus with and without method X, although it is the same as the overriden method,
the ou
so in the following example:
public class Base {
private String field ="base";
public String toString(){
return field;
}
class Derived {
private String field ="derived";
public String toString(){ //method X begin
return field; //method X
} //method X end
public static void main(String[]args){
Derived d=new Derived();
System.out.println(d);//output
}
Thus with and without method X, although it is the same as the overriden method,
the ou
xt
8 楼
sorry. I mean super.t
Well, it is not a good idea to name your variables this way. Don't do it.
【在 n*****r 的大作中提到】
: interesting
: so in the following example:
: public class Base {
: private String field ="base";
: public String toString(){
: return field;
: }
: class Derived {
: private String field ="derived";
: public String toString(){ //method X begin
c*y
9 楼
Sure, if you don't override the toString() method in the derived class, you
will inherit one from the base class but that method only has access to fields
defined in the base class.
If you override it, then you can use a base type to refer to the derived type
and the right method will get called:
Derived d=new Derived();
System.out.println(d); //derived
Base b = new Derived();
System.out.println(b);//derived.
These two calls are the same.
method,
【在 n*****r 的大作中提到】
: interesting
: so in the following example:
: public class Base {
: private String field ="base";
: public String toString(){
: return field;
: }
: class Derived {
: private String field ="derived";
: public String toString(){ //method X begin
will inherit one from the base class but that method only has access to fields
defined in the base class.
If you override it, then you can use a base type to refer to the derived type
and the right method will get called:
Derived d=new Derived();
System.out.println(d); //derived
Base b = new Derived();
System.out.println(b);//derived.
These two calls are the same.
method,
【在 n*****r 的大作中提到】
: interesting
: so in the following example:
: public class Base {
: private String field ="base";
: public String toString(){
: return field;
: }
: class Derived {
: private String field ="derived";
: public String toString(){ //method X begin
c*t
10 楼
Java does not have virtual functions. So der.getValue() and ba.getValue()
do the same thing. If wants to call base overridden functions, have to
use super.
【在 c*y 的大作中提到】
: 1) Define a variable with the same name in a derived class will "hide" the
: variable of the same name in the base class, but it's not called "overidding".
: You only override a method, not a variable.
: 2) Both C++ and Java use static typing, which means the variables are resolved
: at compile time. So if if you directly cast your derived class into a base
: class, and try to refer to the variable, then the one defined in the base
: class will be used. Ex:
: class base{
: public String value = "Base";
: }
n*r
11 楼
Yeah, after reading the bytecode,
the two methods(overidden one in derived and the new one) have the same
bytecodes:
getfiled #3
Then what does the data structure to link methods and instances looks like
in JVM?
【在 c*y 的大作中提到】
: Sure, if you don't override the toString() method in the derived class, you
: will inherit one from the base class but that method only has access to fields
: defined in the base class.
: If you override it, then you can use a base type to refer to the derived type
: and the right method will get called:
: Derived d=new Derived();
: System.out.println(d); //derived
: Base b = new Derived();
: System.out.println(b);//derived.
: These two calls are the same.
the two methods(overidden one in derived and the new one) have the same
bytecodes:
getfiled #3
Then what does the data structure to link methods and instances looks like
in JVM?
【在 c*y 的大作中提到】
: Sure, if you don't override the toString() method in the derived class, you
: will inherit one from the base class but that method only has access to fields
: defined in the base class.
: If you override it, then you can use a base type to refer to the derived type
: and the right method will get called:
: Derived d=new Derived();
: System.out.println(d); //derived
: Base b = new Derived();
: System.out.println(b);//derived.
: These two calls are the same.
n*r
12 楼
Also, there is no way to call the overridden methods outside the derived classes'
method body, right?
【在 c*y 的大作中提到】
: Sure, if you don't override the toString() method in the derived class, you
: will inherit one from the base class but that method only has access to fields
: defined in the base class.
: If you override it, then you can use a base type to refer to the derived type
: and the right method will get called:
: Derived d=new Derived();
: System.out.println(d); //derived
: Base b = new Derived();
: System.out.println(b);//derived.
: These two calls are the same.
c*y
13 楼
In Java, methods are "virtual" by default. Only private, static or final
methods are not virtual. You don't need to put "virtual" when declaring a
method.
You can compile the sample code I gave you and see for yourself.
"overidding".
resolved
Java,
using
variables
the
getInt()
binding.
【在 c**t 的大作中提到】
:
: Java does not have virtual functions. So der.getValue() and ba.getValue()
: do the same thing. If wants to call base overridden functions, have to
: use super.
methods are not virtual. You don't need to put "virtual" when declaring a
method.
You can compile the sample code I gave you and see for yourself.
"overidding".
resolved
Java,
using
variables
the
getInt()
binding.
【在 c**t 的大作中提到】
:
: Java does not have virtual functions. So der.getValue() and ba.getValue()
: do the same thing. If wants to call base overridden functions, have to
: use super.
c*y
14 楼
Usually, dynamic binding is achieved (usually) by using a hidden
virtual-pointer in the class, the virtual pointer will point to a virtual
table, which contains an entry to each of the "virtual" methods (i.e., where
are the code for the method). This hidden pointer is initialized to point to
the right virtual table. So even if you cast your derived class to a base
type, the virtual pointer will still point to the right methods for the right
class.
Don't know if this is the approach taken by Java
【在 n*****r 的大作中提到】
: Yeah, after reading the bytecode,
: the two methods(overidden one in derived and the new one) have the same
: bytecodes:
: getfiled #3
: Then what does the data structure to link methods and instances looks like
: in JVM?
virtual-pointer in the class, the virtual pointer will point to a virtual
table, which contains an entry to each of the "virtual" methods (i.e., where
are the code for the method). This hidden pointer is initialized to point to
the right virtual table. So even if you cast your derived class to a base
type, the virtual pointer will still point to the right methods for the right
class.
Don't know if this is the approach taken by Java
【在 n*****r 的大作中提到】
: Yeah, after reading the bytecode,
: the two methods(overidden one in derived and the new one) have the same
: bytecodes:
: getfiled #3
: Then what does the data structure to link methods and instances looks like
: in JVM?
c*y
15 楼
you
fields
type
classes'
You can't really call an overridden method. If you desperately need to do
that, overload the method if possible or simply give it a different name.
【在 n*****r 的大作中提到】
:
: Also, there is no way to call the overridden methods outside the derived classes'
: method body, right?
c*y
16 楼
Just to give an example; in the example, both the base and derived class has
two methods : equals and compares and they do the same thing, comparing two
objects. But equals() is OVERLOADED in the derived class and compares() is
OVERRIDDEN in the derived class. And you can see the difference between this
two:
class base{
private String value = "Base";
public String getValue(){return value;}
public void print(){System.out.println(getValue());}
public boolean equals(base b){
System.out.p
two methods : equals and compares and they do the same thing, comparing two
objects. But equals() is OVERLOADED in the derived class and compares() is
OVERRIDDEN in the derived class. And you can see the difference between this
two:
class base{
private String value = "Base";
public String getValue(){return value;}
public void print(){System.out.println(getValue());}
public boolean equals(base b){
System.out.p
xt
17 楼
classes'
This is correct. It is a desired behaviour for data prototyping.
【在 n*****r 的大作中提到】
:
: Also, there is no way to call the overridden methods outside the derived classes'
: method body, right?
m*t
18 楼
[snipped]
in
Just a minor note - technically a final method is still a virtual method, only
it cannot be overriden (note "virtual" is a different concept than
"overridable"). It could still have an entry in the table, if it overrides a
method from the base class.
【在 c*y 的大作中提到】
: Just to give an example; in the example, both the base and derived class has
: two methods : equals and compares and they do the same thing, comparing two
: objects. But equals() is OVERLOADED in the derived class and compares() is
: OVERRIDDEN in the derived class. And you can see the difference between this
: two:
: class base{
: private String value = "Base";
: public String getValue(){return value;}
: public void print(){System.out.println(getValue());}
: public boolean equals(base b){
c*y
19 楼
Yes, you can still have an entry in the v-table for the final method, but why
do you want to do that? A final method can't be overridden, so all class
(either derived or base type) will only have one method with that name and it
will be resolved at compile time, then it can't really be called "virtual".
But I can be wrong.
only
a
【在 m******t 的大作中提到】
:
: [snipped]
: in
: Just a minor note - technically a final method is still a virtual method, only
: it cannot be overriden (note "virtual" is a different concept than
: "overridable"). It could still have an entry in the table, if it overrides a
: method from the base class.
do you want to do that? A final method can't be overridden, so all class
(either derived or base type) will only have one method with that name and it
will be resolved at compile time, then it can't really be called "virtual".
But I can be wrong.
only
a
【在 m******t 的大作中提到】
:
: [snipped]
: in
: Just a minor note - technically a final method is still a virtual method, only
: it cannot be overriden (note "virtual" is a different concept than
: "overridable"). It could still have an entry in the table, if it overrides a
: method from the base class.
m*t
20 楼
why
it
Hmm I haven't had my daily coffee today, so correct me if I'm being
stupid. 8-)
You can have:
class Super { public f(){} }
class Sub extends Super { public final f() {} }
somewhere else you have:
Super super = new Super();
Super super1 = new Sub();
super.f();
super1.f();
I don't see how this can be decided at compile time.
I think it's possible to opitimize out the late binding *only if* the final
method does not override another one.
【在 c*y 的大作中提到】
: Yes, you can still have an entry in the v-table for the final method, but why
: do you want to do that? A final method can't be overridden, so all class
: (either derived or base type) will only have one method with that name and it
: will be resolved at compile time, then it can't really be called "virtual".
: But I can be wrong.
:
: only
: a
c*y
21 楼
You are right. I forgot you can override a non-final method by a final one....
hehe.
hehe.
g*e
22 楼
So the modifier 'final' is only used for checking at compile time.
final and non-final methods should be same in bytecode.
Am I right?
【在 c*y 的大作中提到】
: You are right. I forgot you can override a non-final method by a final one....
: hehe.
final and non-final methods should be same in bytecode.
Am I right?
【在 c*y 的大作中提到】
: You are right. I forgot you can override a non-final method by a final one....
: hehe.
xt
23 楼
I think the signature must be different
【在 g*******e 的大作中提到】
: So the modifier 'final' is only used for checking at compile time.
: final and non-final methods should be same in bytecode.
: Am I right?
g*e
24 楼
The caller does not need to distinguish final and no-final methods.
Why bother to make different signature?
Final and non-final methods are all put into v-table, so they are treated
same in run time.
There is no reason to distinguish final and non-final methods in bytecode.
【在 xt 的大作中提到】
:
: I think the signature must be different
xt
25 楼
You are right. There shouldn't be any difference on signature, but
there will be a difference in byte code about the modifier of the method.
【在 g*******e 的大作中提到】
:
: The caller does not need to distinguish final and no-final methods.
: Why bother to make different signature?
: Final and non-final methods are all put into v-table, so they are treated
: same in run time.
: There is no reason to distinguish final and non-final methods in bytecode.
m*t
26 楼
If a final method does not override any other method, a compiler
may choose to optimize all the calls to this method to be static binding.
A final method must be marked in the bytecode, otherwise a compiler would
not be able to prevent it from being overriden (e.g. when the enclosing
class is located in a jar file)
【在 g*******e 的大作中提到】
:
: The caller does not need to distinguish final and no-final methods.
: Why bother to make different signature?
: Final and non-final methods are all put into v-table, so they are treated
: same in run time.
: There is no reason to distinguish final and non-final methods in bytecode.
相关阅读
https certificate??convert array to blob如何看一个xml里的carriage returnjava/J2EE interview questions and answers ebook有谁用过open source ESB 的东东的？OutofMemoryError: Java Heap Spacetype conversionsJava在Web领域是不是太笨重了？Java Swing的UI开发很落后啊简单问题关于中文，能在Java source中直接嵌入吗？HTTP interview question求一本java和算法的书java版不错使用java的大型站点Mushup和SOAAny good Java Profiler (other than Jprobe)?泛型问题so weirdReplay solutions job fair- Sr. Engineer Openings