aspose file tools*
The moose likes Beginning Java and the fly likes reference type URGENT!!! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "reference type URGENT!!!" Watch "reference type URGENT!!!" New topic
Author

reference type URGENT!!!

Brian Smith
Ranch Hand

Joined: Oct 26, 2002
Posts: 232
hi all,
i would appreciate if you any java veteren explains me the following confusions.

now here what does this A refA = new B; mean? i can see that refA is of type A. my question:
is refA is referencing an object of B?
can we access members of B thru refA? if yes or no, WHY?
can we access members of A thru refA? if yes or no, WHY?
thanks.
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8883
    
    5
Namaste -
Why would polymorphism be urgent?
I'm only going to talk about A refA = new B; (sic)
There are a couple of syntax errors here, but I think the real question is about polymorphism so here goes...
Instead of class A and B, let's use something more 'concrete' (a little Java humor ).

So here's what we have:
refA is a reference variable of type Animal, currently referring to an object of type Beagle (a subclass of Animal). Since class Beagle is a subclass of Animal, it can do anything an Animal can do (the eat() method), plus whatever extra methods only a Beagle has (the bark() method).
refB is a reference variable of type Beagle, currently referring to an object of type Beagle.
Using the refA variable you can only call the eat() method, because Animal reference variables only know about Animal methods. However with the refB variable you can call the eat() AND the bark() methods.
Now imagine that you have:

This is an example of polymorphism. You can loop thru the refArray Animal array and call the eat() method on every object in the array, even though the objects are all of different types. (Maybe some of the subclasses have overridden the eat() method). But consider this, it wouldn't make any sense to try to say:
refArray[2].bark();
Penguins don't bark!
The reference variables in the refArray array only know about Animal methods.
Does this make sense?
-Bert
[ June 24, 2003: Message edited by: Bert Bates ]

Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
Brian Smith
Ranch Hand

Joined: Oct 26, 2002
Posts: 232


So here's what we have:
refA is a reference variable of type Animal, currently referring to an object of type Beagle (a subclass of Animal). Since class Beagle is a subclass of Animal, it can do anything an Animal can do (the eat() method), plus whatever extra methods only a Beagle has (the bark() method).
refB is a reference variable of type Beagle, currently referring to an object of type Beagle.
Using the refA variable you can only call the eat() method, because Animal reference variables only know about Animal methods. However with the refB variable you can call the eat() AND the bark() methods.

my question is, if refA is referencing an object of refB, which means, at least in my understanding, refA has an object of Beagle, refB. if so why refA can access members of refB?
could you please explain me?
[ June 30, 2003: Message edited by: Namaste Sathi ]
Steve Morrow
Ranch Hand

Joined: May 22, 2003
Posts: 657

refA and refB point to two different objects of the same class (Beagles, in this case). refA *cannot* access members of refB. An attempt to use refA.bark() will result in a compiler error, as Bert explained above. In order to access Beagle methods, you have to cast refA; e.g. ((Beagle) refA).bark();
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8883
    
    5
Let's look at it this way:
We know that when you create a subclass, instances of that subclass can use the superclass(es) methods, the more you subclass the more methods you have access to... but let's look at this picture:
Assume that each ref. var. is of the type it is next to.

A couple of things to remember:
1- an object lives on the heap, it is not HAD by any reference variables.
2- several different ref. vars can 'refer to the same' object!
So, back to our example from above, rv1 can call ONLY methods from class Object
rv2 can call methods ONLY from class Object or class Animal
rv3 can call methods from class Object, Animal, or Beagle.
Now, when you say:
Animal rv4 = new Beagle();
You are wondering why rv4 can't call the bark() method.
Java is a strongly typed language - that helps you as a developer. Strong typing makes your applications more robust, and it helps you to debug, especially when your programs start to get big. You can imagine the following:
Animal rv4;
// lots and lots of code
rv4 = new Animal();
// lots and lots of code
rv4 = new Beagle();
Through all of this code, rv4 hasn't ever changed its type, it will ALWAYS BE a reference variable of type Animal. It knows ONLY about Object and Animal methods. Even if, somewhere, deep in the bowels of large program, you assign it to a Beagle, it's still of type Animal. It would be REALLY HARD (some might say impossible ), for the compiler to keep track of rv4's current status, and determine whether or not 'now' it's OK for rv4 to invoke the bark() method.
So, to make developing and debugging, and enhancing Java programs more manageable, the compiler just says No. (And I for one am happy that it does ).
-Bert
[ July 02, 2003: Message edited by: Bert Bates ]
Brian Smith
Ranch Hand

Joined: Oct 26, 2002
Posts: 232
now it's apparant that the superclass can't do what subclass can but the otherway around. if so then why do we want to have superclass reference to point to subclass reference? in another words, why do we want do something like the following:
Animal aObj = new Beagle();
can you please explain it?
thanks.
[ July 02, 2003: Message edited by: Namaste Sathi ]
Brian Smith
Ranch Hand

Joined: Oct 26, 2002
Posts: 232
hey Bert,
you said this
Java is a strongly typed language - that helps you as a developer.
could you please explain me what do you mean by that?
thanks.
Joel McNary
Bartender

Joined: Aug 20, 2001
Posts: 1824

Originally posted by Namaste Sathi:
now it's apparant that the superclass can't do what subclass can but the otherway around. if so then why do we want to have superclass reference to point to subclass reference? in another words, why do we want do something like the following:
Animal aObj = new Beagle();

You would use that when you wanted to use only the functionality found in the Animal class. For example, you could represent a Zoo as an array of Animals. When it's feeding time, you simply iterate through the array and call .eat() on each animal--you don't care if its a Penguin, housefly, Platypus, or Beagle.
On the other hand, if you are doing Beagle-related things (such as hunting rabbits), then you need to have the reference type be Beagle.

Generally, you use the "SuperClass aRef = new SubClass();" only when the SubClass does not define new useful methods (such as List as the "superclass" [even though it's an interface, the same thought processes apply], and ArrayList and LinkedList as the "subclasses"). Otherwise, you are likely to have a Factory of some kind to generate the objects:

Here the AnimalFactory could build Beagles, Spiders, Ostriches, GreatWhiteSharks, and we don't care. So long as it's an animal, we're happy.


Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
Joel McNary
Bartender

Joined: Aug 20, 2001
Posts: 1824

Originally posted by Namaste Sathi:
hey Bert,
you said this could you please explain me what do you mean by that?
thanks.

Java is strongly typed in that it enforces type-checking at compile time. Some other languages are "weakly typed;" they will let you do anything with a variable and, if it causes a problem, throw the error at runtime. I would disagree with Bert and state that weakly-typed languages are more robust, but strongly-typed languages are easier to develop in (the compiler will tell you if you've made a logical error).
Compare the following:

with

The two methods do the same thing; the former is written in Objective-C (a weakly typed language) and the latter is written in Java (a strongly typed language). The former will compile and run. If it encounters a problem at runtime (like, the anAnimal parameter is actually a Rock), then it will throw a runtime error ("Class Rock does not respond to method eat:") Note that in Objective-C, the object does not have to be a certain type; it jsut has to respond to the method. You could pass a Plant as the anAnimal method; as long as the Plant class implements the eat: method, it will run and be happy.
On the other hand, Java forces you to have a strongly typed language. The correct form of the method should be

or

Of course, in the latter case you would have to watch out for ClassCastExceptions. Having the former ensures at compile time that whenever the method is called, it is garunteed to have an Animal object and a Food object.
You can weakly type Java by using Reflection; in my opinion, that is where Java's robustness comes in. It can be make to simulate a weakly-typed language (just try writing a generic BeanBox-type thing in C++; it's a mess! You need the weak-typing for that robustness), but it also protects the user from making Really Dumb Mistakes(TM)
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Joel McNary:
Java is strongly typed in that it enforces type-checking at compile time. Some other languages are "weakly typed;" they will let you do anything with a variable and, if it causes a problem, throw the error at runtime.

No, sorry - that's not strongly versus weakly typed, but statically versus dynamically typed.
The former refers to wether *objects* have types. Both Java and Smalltalk are strongly typed, that is, an object knows its type and you get an error if you try to call a message on it it doesn't understand. Early C++ was weakly typed: you could cast any object to any type without getting an error (besides strange behaviour of the system, of course). Newer versions add the option to work strongly typed, too.
The latter refers to wether *variables* have types. In statically typed languages like Java, you can't assign an object to a variable with incompatible type. In such languages, polymorphism is typically strongly bound to inheritance, causing some structural problems. In dynamically typed languages, you can assign any object to any variable - and consequently call any method on any variable. Type errors are only found at runtime; polymorphism and inheritance are fully "decoupled".
Did that help?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joel McNary
Bartender

Joined: Aug 20, 2001
Posts: 1824

Whoops...sorry, you're right. My brain slipped away for a moment and I went down the wrong path.
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8883
    
    5
From the 'Can of Worms' department.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: reference type URGENT!!!