A quick example
class A {
protected int foo(int x){
return x;
}
}
class B extends A {
public int foo(int x){
return x*x;
}
}
This is allowed in Java and works without any issue. But let's say in another package you declare
A b = new B();
int z = b.foo(5);
Then this won't work because obviously A foo() is protected. But then why allow in the first place to have more accessible methods in the subclasses? Is there a case where this is helpful?
In general, subclasses can add methods to the interface they inherit from their parent class. Making a method more accessible is effectively adding to the interface.
But then why allow in the first place to have more accessible methods in the subclasses?
Because it can be useful for code that holds a subclass reference.
Is there a case where this is helpful?
One good example is Object.clone(), a protected method. All Java classes are subclasses, directly or indirectly, of Object. Subclasses that support cloning can choose to make this method public.
Foo foo1 = new Foo();
Foo foo2 = foo1.clone(); // Sometimes you're holding a subclass reference.
Because classing is supposed to allow you to think of subclasses as instances of their superclasses. I think this is called an is-a relationship (namely B is-a A, but not the other way around). I don't really know a good way to explain this succinctly.
In your example, all instances of B are also instances of A (be mindful this may be a gross oversimplifaction, but I think for this example it is enough). A only guarantees to have methods that are public in its own definition. B just happens to make one of the protected methods public, but let's suppose you had another class called C that did not do this. Well, you can cast both B and C into A, but if you were allowed to call the protected method on A because B makes it public, then you would get an error when you pass C.
In the other package, you're casting B to A, so your object effectively takes on the interface of A so you are restricted to use only the interface given to you by A. Can the JVM go through the trouble and notice that 1) A is in fact B and that 2) B makes foo public, so foo should be callable? I mean it could I suppose, but how much effort would that take to implement in the JVM and how error prone would that be? Keep it simple. If the type is A, then the interface is A. If the type is B, then the interface is A and whatever else B includes on top of that.
You could make the second example compile if you replaced A with B. That's the point: B can be used everywhere A can, but can also add additional features (such as making methods public).
Related
I'm confused why this code works.
The object "person" is declared as an instance of B with only the functionality of A, yet it somehow prints out hello twice. If the object only gets access to the methods in A, how can it end up accessing the print out statement?
abstract class A {
abstract void move();
void go() {
this.move();
}
}
class B extends A {
void move() {
System.out.println("hello");
}
}
public class Main {
public static void main(String[] args){
A person = new B();
person.move();
person.go();
}
No, you have a "link" of class A, but functionality depends on object (in your code it is new B();), so your A link points to a B object with B functionality.
The object "person" is declared as an instance of B with only the functionality of A
Not exactly. Java is a reference-based language; here you have made an instance (new B()), and have exactly one reference to it, called person.
You could have no references to it (leading to the created object being garbage collected eventually). You can have 2000 references to it. You could have B b = new B(); A a = b;, and now you have 2 references to it, one of type A and one of type B. But they are pointing to the exact same object.
Thus, person isn't an object, it's a reference. And that reference has type A, sure, but the object it is referencing is just a B, it isn't 'restricted' to have only A functionality.
You probably know all this, but terminology is important here, as it seems to have led to some confusion. Restating your question with less ambiguous terminology:
The reference "person" currently references an instance of B, but only exposes functionality that A has.
Yes. And A's functionality is described solely by the signatures present there, not by the code. A's functionality involves having a go() method, which takes no arguments and returns nothing, as well as a move() method with the same rules. And that is all - 'invoking go will actually run the move method', or 'move has no implementation' is not part of that.
Thus, both move() and go() are part of the functionality exposed by A.
The implementation of the functionality has nothing whatsoever to do with the reference type (A person) and everything to do with what the reference is actually pointing at (new B()). B's implementation of the move() and go() methods specified by A are such that move prints "hello", and go() calls move (thus, prints hello()) - that implementation is inherited from A, but B was free to change that; B however decided not to.
Said more technically:
Java uses something called dynamic dispatch. What that means is that at compile time (i.e. write time), java figures out if a method you're calling even exists and which variant (if you have move(String a) and move(int a), that's two methods with the same name, at write time java decides which one you are attempting to invoke), and uses the type of the expression in front of the dot to figure that out. But then at runtime, the actual type of the object that 'the expression in front of the dot' is actually pointing at is used to figure out which actual code to invoke. This always happens and you can't opt out (you can't choose to run A's implementation when you invoke main(). Only B's implementation can choose to not override A's implementation, or to explicitly invoke its supertype's implementation. A user of B's code cannot do that).
Note that static stuff doesn't 'do' inheritance at all, and therefore, dynamic dispatch doesn't apply there.
In Java, I was given an assignment. I could describe my issue with it generally as follows:
Create three classes A B and C.
Class A has instance variables j,k,l, setter and getter methods, and also method x which makes a calculation based on them.
Class B is a subclass of A and overrides method x with the same empty signature, using j,k,l.
Class C is also a subclass of A, and has an additional class y which does other junk.
Now, instantiate a class C object, set its variables, execute method x and then use the overriden version of method x from class B.
My question is, how do I do that last part? I think either the question is incorrect or else I am interpreting it wrong. Can I cast my class C object to a class B object and then use the class B version of x()? I don't know much about casting objects and what determines whether it is possible to cast from one thing to another. Upcasting could be just as lossy as "horizontal/lateral" casting but I have never heard of the latter. Is it impossible to use the method in class B from class C without making class C internally instantiate and rebuild a class B object from its own variables? Am I making sense?
Addendum:
Okay. So siblings cannot be cast as one another? Because C and B are both "part of [my] object hierarchy". Could I cast up and then back down to a different subclass? Like casting a cat to an animal class and then an animal to a dog? Because method x relies on instance variables in both class A AND class B, creating a new instance of B within C will create an object with fields/variables which are not set the same, they will all be zero or similar. So I will have to essentially have to copy over each value of j,k and l into the new B type object within the C class object. This seems like a waste of time and memory, copying the object variables into another very similar object. But there is no other way?
Second Addendum:
Although I have selected an answer, I am still curious about casting in general and what I call lateral-casting. If B and C are both sub-classes of A, can you allow casting from B to C? Also, how does one allow casting in general?
Third:
So at this point, a couple years later I understand that this is not really possible in Java. However, interestingly in JavaScript and PHP you can use the "bind" method of a function to change it's context so that it essentially thinks it's another object. So in this scenario I could create a copy of B:x() bound to an instance of C containing the properties I have set, the bound instance of x would then use all of the internal variable of the instance of C. It's really weird but really handy sometimes.
Here is an example of using a method from one subclass on a different subclass; making a cat speak using a dog's speak function:
class Animal {
constructor(){
}
}
class Dog extends Animal{
constructor(){
super()
this.sound = 'bark'
}
speak(){
console.log(this.sound)
}
}
class Cat extends Animal{
constructor(){
super()
this.sound = 'meow'
}
}
var mycat = new Cat()
var mydog = new Dog()
mydog.speak()
mydog.speak.bind(mycat)()
So it's basically as if cat has the speak function. This is the sort of thing I wanted to do in Java.
Casting means you know better than the compiler what your object is. If you cast to something that isn't part of your object hierarchy you will get an exception (specifically a ClassCastException) when you run the program.
The most common place you see casting is in the Object#equals method. equals needs to take a java.lang.Object as its only argument. If you look at how people implement equals, you'll see testing for what the class of the passed-in object is, and if it's what's expected then there's a cast so that the checks that follow can use that object's fields. Otherwise casting doesn't come up in beginner situations much.
Casting does not change what your object is, it only tries to inform the compiler what the object is in circumstances (like equals) where the type system is not sufficient. If you are creating objects with virtual methods in a hierarchy, casting does not change which version of the method gets called.
If C is not a subclass of B then you can create an object of class B within C, as an instance member or as a local variable of some method of B, and call the method of C on that, something like:
class C extends A {
private B b; // instance member
public C(B b) {
this.b = b;
}
public void x() {
// do stuff
b.x();
}
}
I have some class X with the field A in it. It is a final field, initialized in constructor. Now I have a derived class Y where this field must always be an instance of B, a class that is derived from A. The problem, the class Y needs to call a number specific methods that are only available on the class B but not on its ancestor, A.
I see several solutions:
Reuse the field of the type A, inherited from X, and inside the class Y, cast A to B. This makes my code full of nasty type casts.
Add another field of the type B. Now there are no typecasts but we have two fields of slightly different type that must always hold the same value - also does not feel good.
Add all methods that B provides also to A, throw NotImplementedException. This adds some strange methods that knowingly make no sense in that class.
Which is the most right way to deal with this field? Or maybe some other, better exists? I do not think this is very language specific but must be doable in Java I am using.
The X type should probably be a generic type:
public class X<T extends A> {
protected T a;
public X(T a) {
this.a = a;
}
}
public clas Y extends X<B> {
public Y(B b) {
super(b);
}
public void foo() {
// here, this.a is of type B, without any type cast.
}
}
The only sane solution I can think of is a variation of #1: add to class Y a getter method that returns the field cast to the type B, and access the field only through this getter. That will only require one cast, and as a beneficial side effect it will also document which parts of the code require that the field be actually a B.
Solution #1 is the most correct way, in my opinion. If you know that an object is of a specific class, there's nothing wrong with casting it to that class. It'd be wrong if you were making assumptions while doing this, but this is not an assumption, according to what you're saying. Maybe make a getter method that simply casts the underlying field to the correct type and be done with it? That way, you'll only have to cast once (per subclass).
Solution #2 will cause elusive runtime errors if the fields somehow cease being properly up-to-date with each other. This seriously sounds like the worst solution.
Solution #3 still feels like bad software design. If a method exists and it's not in an abstract class and you are not in a prototyping phase, then that method should be implemented. Otherwise, you're probably just planting unnecessary traps for the user (of the class) by giving it a misleading interface.
class A
{
int i=10;
void show()
{
System.out.println("class A");
}
}
class B extends A
{
int i=5;
public void show()
{
System.out.println("class B");
}
}
class M
{
public static void main(String s[])
{
A a=new B();
a.show();
System.out.println(a.i);
}
}
OUTPUT= class B
10
If class A method is overridden by class B method then why not the variable 'i'?
Because variables are not virtual, only methods are.
It is not overwritten, but hidden. In your output you specifically requested the value of a.i, not ((B)a).i.
This is a "feature" of the implementation. In memory, this looks like so:
a:
pointer to class A
int i
b:
pointer to class B
int i (from A)
int i (from B)
When you access i in an instance of B, Java needs to know which variable you mean. It must allocate both since methods from class A will want to access their own field i while methods from B will want their own i (since you chose to create a new field i in B instead of making A.i visible in B). This means there are two i and the standard visibility rules apply: Whichever is closer will win.
Now you say A a=new B(); and that's a bit tricky because it tells Java "treat the result from the right hand side as if it were an instance of A".
When you call a method, Java follows the pointer to the class (first thing in the object in memory). There, it finds a list of methods. Methods overwrite each other, so when it looks for the method show(), it will find the one defined in B. This makes method access fast: You can simply merge all visible methods in the (internal) method list of class B and each call will mean a single access to that list. You don't need to search all classes upwards for a match.
Field access is similar. Java doesn't like searching. So when you say B b = new B();, b.i is obviously from B. But you said A a = new B() telling Java that you prefer to treat the new instance as something of type A. Java, lazy as it is, looks into A, finds a field i, checks that you can see that field and doesn't even bother to look at the real type of a anymore (because that would a) be slow and b) would effectively prevent you from accessing both i fields by casting).
So in the end, this is because Java optimizes the field and method lookup.
Why no field overrides in Java though?
Well, because instance field lookups in Java happen at compile time: Java simply gives you the value of the field at a given offset in object's memory (based on the type information at hand during compilation: in this case a is declared to be of type A).
void foo() {
A a = new B();
int val = a.i; // compiler uses type A to compute the field offset
}
One may ask "Why didn't compiler use type B since it knows that a is in fact an instance of B? Isn't it obvious from the assignment just above?". Of course, in the case above, it's relatively obvious and compiler may try to be smarter and figure it out.
But that's compiler design "rat hole", what if a "trickier" piece of code is encountered, like so:
void foo(A a) {
int val = a.i;
}
If compiler were "smarter", it would become its job to look at all invocations of foo() and see what real type was used, which is an impossible job since compiler can not predict what other crazy things may be passed to foo() by unknown or yet unwritten callers.
It's a design decision by the developers of Java, and is documented in the Java Language Specification.
A method with the same method signature as a method in its parent class overrides the method in its parent class.
A variable with the same name as a variable in its parent class hides the parent's variable.
The difference is that hidden values can be accessed by casting the variable to its parent type, while overridden methods will always execute the child class's method.
As others have noted, in C++ and C#, to get the same override behavior as Java, the methods need to be declared virtual.
a is an instance of A. You call the constructor B(). But it is still a A class.
That is why i equals 10;
The override from the method will be succeded.
Note a class starts not with
public class A()
but with;
public class A { ... }
Tip: You can use setters and getters to make sure of what data-members you use.
Or: You simply can set the values at the constructor instead of the class declaration.
Because by default the variables are private. You must declare it as "protected", then will be properly inherited.
I have something unclear concerning casting reference variable in Java.
I have two classes A and B. A is the super class of B.
If I have the two objects, and then the print statement:
A a = new A(); //superclass
B b = new B(); //subclass
System.out.println ((A)b);
then what exactly is happening when the println method is executed?
I know that because B is a subclass of A, I am allowed to make the following cast:
A a2 = (A)b;
I also know that when println takes a reference variable as argument, then the toString() method of the class, which has created the object-argument, is invoked (implicitly). This is so, because the method println() is looking for an argument of type String, and the toString() method represent the object as a string. And even if we don't write toString(), the method is invoked - implicitly. So, the following two statements are equivalent:
System.out.println (b);
System.out.println (b.toString());
So, my question is: what is the implicit action taken when we have
System.out.println ((A)b);
?
I suppose that the type of the reference variable b is automatically changed from B to A. The variable should still be pointing to the same object - the one created with
B b = new B();
but just the type of b would be now changed. Is this correct?
Another question: even though I have changed the type of b to the type of the superclass, are the overriden methods in the subclass going to be called, and not those of the superclass?
Thanks a lot.
Regards
The cast has no impact in this case.
The System.out.println(XXX) takes parameters of different types (multiple overloaded versions) but in this case you would get the version that takes Object. Since every object in Java supports toString(), toString is invoked on the actual argument, no matter what it is.
Now, since all methods in Java are dispatched dynamically, the version that runs is the version that corresponds to the dynamic type. Casting an object of B to A only changes the static (declared) type of the expression. The dynamic type (what's really in there) is still a B. Therefore, the version in B gets invoked.
There are many declarations of println(...) in the PrintStream class (which is the type of System.out).
Two of them are:
void println(String x)
void println(Object x)
When you call println((A)b) the compiler chooses to call println(Object) because A is not String (or any of the other types that println supports). When you call println(b.toString()), the compiler chooses println(String) because you are passing a String.
In your case, casting b to A has no effect since println() doesn't have a declaration for either A or B types. But the cast will still occur (because you asked for it), or maybe it won't because the compiler optimises it away as it knows it is redundant and it can't fail and has no effect.
It is not idiomatic to write:
A a2 = (A)b;
as this is redundant since B is a subclass of A. It may be that the compiler will optimise away the cast (which is a run-time operation to check whether an object is of a particular type, never to change it's type).
Once an object of type B is constructed, it's type never changes. It is always a B:
class B extends/implements A {...}
B b = new B(); // construct a B
A a = b; // assign a B to an A variable, it's superclass
A a = (A) b // as above including check to see that b is an A (redundant, may be optimised away).
B b = a; // Syntax error, won't compile
B b = (B) a // Will check whether a is of type B then assign to variable b
In the last case, since B is a subclass of A, it may be that a holds an instance of B and the cast will succeed. Or it may be that a holds an instance of some other class that extends/implements/is A and isn't a B and you'll get a ClassCastException.
So since an object of type B always retains it's identity (it's "B"-ness) then any (instance-) methods called on that object will always call B's implementation regardless of whether the variable through which you access the object was declared as A or B.
Remember, you can only call methods that are declared in the class that the variable is defined as.
So for example, if B declares a method b_only() then the compiler won't allow you to write a.b_only(); you could write ((B)a).b_only() though.
Since Java methods all have dynamic dispatch, which function gets called doesn't depend on the static type of the reference. Therefore, the results will be the same with or without the cast. [The results could be different if you were downcasting - the casting version could throw an exception]
Is this correct?
Sort of. The result of the casting expression would be of the A type. The type of the 'b' variable will always remain of type B.
Another question: even though I have changed the type of b to the type of the superclass, are the overriden methods in the subclass going to be called, and not those of the superclass?
The instance methods of the underlying object will be called. Example:
class Foo {
public static void main(String[] args) {
B b = new B();
assert "B".equals(((A) b).m());
}
}
class A {
String m() { return "A"; }
}
class B extends A {
String m() { return "B"; }
}
Always think of your object as the type it's instantiated as (B in your case). If it's upcast to A think of it as--hmm--think of it as B putting on A clothes. It may look like an A, and you may not be able to do any of the nice B things you want to do, but inside the clothes it's still a B--the clothes don't change the underlying object at all.
So the summary would be--you can only call the methods in A, but when you call it, it goes straight through and executes it as it would if it was a B.
I think when we use reference variable in java and by using this variable we can assign a object of any class type. most of the cases we create a reference variable of Interface and abstract class because we can't create the object of interface and abstract class so assign the object of class in reference variable of Interface or abstract class.
Ex-
Interface X {
public abstract void xx();
public abstract void yy();
}
Class XXX implements X {
...........
}
Class XY extends XXX {
X xy = new XXX();
}
here xy is a reference of Interface X and assign the object of Class XXX in the reference of Interface.
so according to my point of view by using reference variable we can also use interface to participate in Object creation.
The casting, as has been mentioned, is irrelevant in this case due to overridden methods being dynamically bound. Since the toString is present in all objects it meets this condition and thus the object type and method to call are determined at runtime.
Please note though, this is NOT the case with all methods since only overridden methods are dynamically bound. Overloaded methods are statically bound. Many of the answers here mention that java methods are always dynamically bound, which is incorrect.
See this question for a more detailed explanation.
question: even though I have changed the type of b to the type of the superclass, are the overriden methods in the subclass going to be called, and not those of the superclass?
in this case the method of subclass b is called ; to convincingly understand why; you may relate to the following real world scenario
consider a parent class Father exhibiting a behaviour(method): height
defined as
the father is tall ;height = 6'2"
Son is a child class inheriting the height behavior from Father ;as a result he is also tall; height being 6' clearly overriding the behaviour
whenever your subclass Son calls the behavior height on his name he displays the overridden behavior i.e his own height 6' .