aspose file tools*
The moose likes Beginning Java and the fly likes Polymorphism Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Polymorphism" Watch "Polymorphism" New topic
Author

Polymorphism

Mark Howard
Ranch Hand

Joined: Feb 14, 2001
Posts: 285
Just read the Javaranch article "How my Dog learned Polymorphism". Brilliant. I wish more textbooks would use a simple approach to explaining their content.
I am however still unclear on the use of instance variables when Polymorphism is in action. Consider the following, given the Dog-extends-Animal analogy in "How my Dog learned Polymorphism":
1) I add an instance variable (say x) to the Dog class.
2) I then create a new Dog object with an Animal reference using: Animal d = new Dog().
3) I then try to reference variable x in a statement such as: System.out.println( "x = " + d.x );
The compiler didn't like it. I then made variable x a class variable with the 'static' modifier, and the program compiled and executed ok.
So it appears to me that I can access the class variables of an object that was instantiated using the superclass as a reference, but am not allowed to access the instance variables of the same object.
Can anyone explain ?
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
The thing to understand is the timing of the creation of each thing.
The static variable was created when the class was loaded. It is there to be referenced even if there are NO instances of the class that it belongs to.
When d is declared (when you say Animal d; )the variables for Animal are created in memory. Not to confuse the object variable d (the "holder") with the internal variables that d has which may be either primitive or object variables themselves.
When an object variable is instantiated (when you say d = new dog(); ) the dog object is created on the heap and the reference to it placed in d. Methods are resolved at runtime, so the methods that d uses will be the Dog object methods, however variables are resolved at compile time, so the variables that d uses are the variables of Animal.
As long as your Dog object is in an Animal variable it will only be able to reference the instance variables of Animal.
So - yeah - you are right.


"JavaRanch, where the deer and the Certified play" - David O'Meara
Graeme Brown
Ranch Hand

Joined: Oct 13, 2000
Posts: 193
Mark
I think your problem is more to do with inheritance than polymorphism, although the two concepts are related. Take a look at the following code:

You will see that polymorphism works the same way both for instance variables and methods, tiddles outputs Animal and fido outputs Dog in both cases of accessing name.
The difference occurs when we try to access the sound instance variable. Although we know that fido is a Dog, that may not always be the case. fido is a pointer to an object of type Animal, and so could be made to point to a Cat object or any other Animal for that matter:
fido = new MuteSwan(); //assuming MuteSwan extends Animal
trying to access sound for a MuteSwan would not make sense, so we have to explicitly tell the JVM that we know fido is a Dog by using an explicit cast - (Dog) fido
Hope that helps.
Graeme
Graeme Brown
Ranch Hand

Joined: Oct 13, 2000
Posts: 193
Sorry Cindy our posts crossed.
We are approaching the problem from slightly different angles, but I agree with everything you say.
Graeme

Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
There is always room for two explainations of the topic. Thanks for showing the code.
ekarit srisuparb
Greenhorn

Joined: Feb 26, 2001
Posts: 2
How do we call the class with methods that must be overridden in a derived class?..Is it interface class or inherited class?...
Graeme Brown
Ranch Hand

Joined: Oct 13, 2000
Posts: 193
There are two ways in Java to achieve this. An "abstract class" contains abstract methods, which have a method definition but no implementation. These methods must be overridden in subclasses to provide the implementation. An abstract class may contain non-abstract methods.
An "interface" is a special case of an abstract class, which contains only abstract methods and final variables. No implementation is allowed in an interface.
So the answer to your question is the class that must be overridden is an abstract class or interface, which is the parent class, or superclass.

[This message has been edited by Graeme Brown (edited February 27, 2001).]
madhesh raj
Ranch Hand

Joined: Nov 28, 2000
Posts: 62
Hi Mark,
I just tried an example to check out what u said. I have given the code below. Irrespective of whether i put x as static in class Rohit or not, the object always tries to access the x in the main class Poly. If it doesn't find x, it gives a compilation error.
Seems ur theory is wrong mate
Madhesh

class Poly
{
int x = 60;

void sayHello()
{
System.out.println("Hello Poly");
}

}

class Rohit extends Poly
{
static int x=50;

/*Rohit()
{
x = 100;
}*/

void sayHello()
{
System.out.println("Hello Rohit");
}

}
public class PolyTest
{
public static void main(String [] args)
{
Poly obj1 = new Rohit();
System.out.println("value = " + obj1.x);
obj1.sayHello();
}
}
jamie bowden
Greenhorn

Joined: Feb 05, 2001
Posts: 3
With Abstraction, does the general abstract class method header have to be the same as its children?
e.g
Abstract class X
method t (int r);

class y extends x
method t (int e){
}

Do the method signatures need to be the same? Every book i've seen only does the method x() and nothing with parameters in the signature.
Jamie

Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
Yes the signatures need to be the same. However in the example that you have given, they DO have the same signature. What you call the parameter that is input does not change the signature.
(Course you typoed on the extends X so . . .)
In the implementation in the sub-class you can have ADDITIONAL overloaded methods that provide different signatures.
jamie bowden
Greenhorn

Joined: Feb 05, 2001
Posts: 3
Therefore
For abstract methods is it best to always declare the method signatures as return type void, no parameters so that you can override the methods further on down?
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
If you declare them void here, you have to declare them void in the implementation. You should declare them what they need to be. Remember the reason that you are creating an abstract method is to FORCE some particular behavior in the implementing classes. Just trying to make it as bland as possible will not get desired the results.
abstract class Car(){
abstract FuelType getFuelType(){};
}
This will force the implementing class to have a method that returns the correct type of fuel to use for this car. You want them to provide that return type, and you can not count on everyone down the line being COOL enough to think of all of the behaviors that YOU can think of.

[This message has been edited by Cindy Glass (edited March 01, 2001).]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Polymorphism