#Refrences and object type

1 messages · Page 1 of 1 (latest)

arctic yacht
#

can someone help me understand what we mean by refrence and object type
like when we do for example Animal A = new Dog()

misty jayBOT
#

<@&987246399047479336> please have a look, thanks.

#

Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In any case, a human is on the way 👍. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.

#
TJ-Bot
Can someone help me understand what we mean by refrence and object type like when we do for example Animal A = new Dog()

In Java, reference type and object type are important but distinct concepts:

  • Reference type: This is the type of the variable holding the reference to the object. In your example, Animal A means the reference type is Animal. It determines what methods and fields you can access via A at compile-time.

  • Object type: This is the actual type of the object created by new Dog(). Here, the object type is Dog. At runtime, the JVM knows the actual type of the object which affects which overridden methods are called (dynamic dispatch).

So, when you write Animal A = new Dog();:

  • A is a reference to an Animal, so you can only call methods defined in the Animal class/interface.
  • The real object is a Dog, so if Dog overrides some methods from Animal, the Dog methods will be executed at runtime.

This distinction is key for polymorphism in Java — you program to an interface (reference type) but the behavior depends on the actual object (object type).


Useful links:

ember timber
#

Are you talking about interfaces and their implementations?

arctic yacht
#

yes

ember timber
#

What do you not understand?

arctic yacht
#

like for example if we do Dog A = new Dog() we create a variable thats type dog and we can use all its methods but if we do Animal A = new Dog() we can use only the Animal methods

#

whats the point of ever doing Animal A = new Dog()

#

i dont get the concept of refrences

molten glacier
#

We'd write the example as

Animal a = new Dog();

a is a reference. It's type is Animal. It can be null or refer to any object of type Animal or a subtype of Animal.

new Dog() creates a Dog object and returns a reference of type Dog. We can assign that to a reference of type Animal because Dog is a subtype of Animal.

arctic yacht
#

but why not just do Dog a = new Dog();

#

doesnt that do the same thing

molten glacier
#

This is useful for a few reasons.

  1. It communicates to the reader, that they should not assume anything more specific than Animal when using a.
  2. If we change our minds about the actual type of the object, eg Cat, the only place we need make that substitution is this point of assignment.
  3. Imagine we had a method return a random animal. At that point we'd need to use type Animal regardless of the actual type of the object.
arctic yacht
#

Animal a = new Dog(); so this makes the a type dog and it referes to an animal

ember timber
molten glacier
#

That point 3 also applies to taking arguments. Consider this method...

public static void <T> print(ArrayList<T> items) {
    for (T item : items) {
        IO.println(item);
    }
}

I can only pass a ArrayList to this method. What if I had a LinkedList, or a Set, or some other Collection? What if all I had was something that is Iterable? Writing the method with the more general type would allow far more reuse of the method.

public static void <T> print(Iterable<T> items) {
    for (T item : items) {
        IO.println(item);
    }
}
arctic yacht
#

and i can only use the methods of the refrence type

molten glacier
#

Yes, you can only access the methods of the reference type (not the object type). So if you needed methods specific to Dog you would obviously use Dog d = ....

arctic yacht
#

so we use the refrence to be more general?

#

and we make the object the type of the more specific?

molten glacier
#

We generally aim to be as general as makes sense to the usage at hand.

arctic yacht
#

thats the same for interfaces right

#

for example class A implements interface B we would do interface B = new class A

#

but then we cant use any methods

molten glacier
#

Yes. In fact we tend to prefer interfaces over deep object hierarchies. Overusing inheritance tends to make decisions harder later if you need to change the shape of the model, and they are less flexible for callers as well.

#

The rules for which methods you can call are the same. You can only access the methods of the "reference type"

arctic yacht
#

hmmm alright

#

makes sense

#

but its actuall data is the object type right

molten glacier
#
List<String> names = new ArrayList<>();
names.add("Bob");
arctic yacht
#

is the refrence like a pointer?

molten glacier
#

Sort of like a pointer. It isn't necessarily a memory address - and so might be an actual pointer to memory, or it might not (and often isn't). It refers to an object by whatever means your JVM is using.

arctic yacht
#

alright thanks i get it now i think

#

also for interfaces if i make an array of an interface and the refrence is that interface the object type can only be a class the implements it rigt

molten glacier
#

Yes. You can never reference an incompatible type

arctic yacht
#

ok thanks again

vernal turret
arctic yacht
#

a bit

#

first semester

vernal turret
# arctic yacht a bit

a pointer is something more specific
a reference is more abstract you don't need to know how it is implemented, just how to use them

civic dawn
#

So basically Animal class is the reference type and the Dog class is the object type

#

Because, dog is an animal , we extend dog class from animal class

#

And when one class extends another, the object type i.e the place where we wrote Dog can be one of it's extended classes

molten glacier
#

And if Animal is an interface, there is nothing limiting your choice of object type as long as that type (or a super type of it) implements Animal.

when you then call a method on the Animal typed reference a, the compiler check the call against matching signatures on Animal. If Dog had a more specific match (an overloadef method), the compiler will not consider that, looking only at the reference type.