Method signature (Chapter : Abstract class and Polymorphism)
Hi all,
I found some quaint thing about signature method. It's said: "A child class may define additional methods with signatures different from the parent's method." but
"It is an error if a child defines a method with the same signature as a parent method, but with a different return type."
The thing is: return type is not belong to method's signature !!!
Can someone explain this point?
Thanks and have a nice day ( 11:00 am in Germany)
H.A
[491 byte] By [
Pupicea] at [2007-10-2 6:01:50]
Hi,
By definition, the signature of a method is the method's name and its parameter list.
Two methods have the same signature if you can write them the same when you call them.
Let's have:
interface Toto {
public int doSomething(String parameter);
}
interface Titi {
public String doSomething(String param);
}
Those two methods have the same signature:
Toto toto;
Titi titi;
toto.doSomething("something");
titi.doSomething("something");
As an example, you cannot define a class like
class Foo implements Toto, Titi {
/** Toto implementation */
public int doSomething(String parameter) {
return 0;
}
/** Titi implementation */
public String doSomething(String parameter) {
return parameter;
}
}
Obviously, a problem would occur if you call one of these methods on a Foo instance:
Foo foo;
foo.doSomething("foo");
Hope it helps.
Thanks for instant reply.Is the abstract class or normal parent class behaved like interfaces in this case? because i am reading abstract class and Polymorphism.
> "It is an error if a child defines a method with the
> same signature as a parent method, but with a
> different return type."
> The thing is: return type is not belong to method's
> signature !!!
> Can someone explain this point?
Yes.
Even though return type isn't part of the "signature" (as the JLS defines "signature"), the JLS requires that child methods with the same signature as parent classes have the same return type.
Think about it for a minute: Return type isn't part of the signature, but it is part of the contract. If Parent has public Whatsit foo()
then it's promising that every instance of Parent, AND every instance of any Child that is a subclass of Parent (since a Child also IS A Parent), will have that method, and callers of that method will receive a Whatsit as a return value.
If I try to override it in Child with public Doobley foo()
then a call might try to do this: Parent parent = factory.createParent(); // happens to return a Child, which is allowed, because a Child is a Parent
Whatsit w = parent.foo(); // OH NO! We got bad a Doobley instead of a Watsit!
See the problem?
Now, it turns out that 1.5 adds covariant return types, which allows a child method to return a subtype of what the parent returns. So the above would work IFF Doobley is a subclass or subinterface of Whatsis, or is a class that implements Whatsis. This works because the child is still keeping the parent's contract. He's just actually promising a bit more than what the parent promises.
> Thanks for instant reply.
> Is the abstract class or normal parent class behaved
> like interfaces in this case? because i am reading
> abstract class and Polymorphism.
The same rules apply whether the types in question are interfaces, abstract classes, concrete classes, or a mixture.
oops !!! wrong click.
Thanks for instant reply.
Is the abstract class or normal parent class behaved like interfaces in this case? because i am reading abstract class and Polymorphism. The reason i com to this question is since a class can inplement several Interfaces, it can inherit from only 1 abstract class. So i found no reason to have 1 method which similar to abstract class but different return type.
MfG
> The reason i com to this question is since a class can inplement
> several Interfaces, it can inherit from only 1 abstract class. So i found
> no reason to have 1 method which similar to abstract class but
> different return type.
There is at least no good reason...
Note that a class can extend an abstract class and implement one or more interfaces (e.g. you can make Toto being an abstract class instead of an interface in my exemple above.)
Or you might wish to declare a new method yourself in subclass with the same signature as one of the parent class, but with a different return type...
The fact is that it is forbidden and you know why now.
More about method names and signature:
Three situations might cause a method to have the same name as other methods in the class or in a superclass: overriding methods, hiding methods, and name overloading.
Name overloading means that multiple methods in the same class can share the same name if they have different parameter lists.
A method with the same signature and return type as a method in a superclass overrides or hides the superclass method:
- The overriding method has the same name, number and type of arguments, and return value as the method it overrides.
- If a subclass defines a class method with the same signature as a class method in the superclass, the method in the subclass hides the one in the superclass.
> oops !!! wrong click.
>
> Thanks for instant reply.
> Is the abstract class or normal parent class behaved
> like interfaces in this case? because i am reading
> abstract class and Polymorphism. The reason i com to
> this question is since a class can inplement several
> Interfaces, it can inherit from only 1 abstract
> class. So i found no reason to have 1 method which
> similar to abstract class but different return type.
> MfG
Like I said: interface, abstract class, or concrete class, the same rules apply.
