Why declare an object and instantiate it as instance of inherited type?

[Tom Brodhead]

I'm unclear about the utility (as well as the true meaning) of declaring an object of one type but then instantiating it as an instance of an inherited type.

For example, let's say I have a Fruit class and two inherited classes Apple and Orange, each of which extends Fruit:

class Fruit(){...whatever...}
class Apple extends Fruit (){...whatever...}
class Orange extends Fruit (){...whatever...}

Now, I understand I can declare an object this way:

Fruit x = new Apple();
Fruit y = new Orange();

But not:

Apple a = new Fruit();
Orange b = new Fruit();

...because Fruit() well might not have all of the properties of either Apple or Orange (am I right?)

But why would you do:

Fruit x = new Apple();

...when you might as well do:

Apple x = new Apple();

???

What utility is there in the former case? What might x have when declared one way as opposed to the other? What are the situations where it provides an advantage?

And in general, why would we even need the Object type on the left side of the statement, anyway? Why not simply:

x = new Apple();

I think this points at a subtlety of a fundamental property of object instantiation that I don't grasp fully. Many thanks in advance for the help!

~~Tom

[Stephan van Hulst]

https://coderanch.com/t/510989/java/java/reference-type#2310726

As for why a variable is declared in the first place, is to ensure type safety. If you don't declare your variables before you use them, how can the compiler check whether you're performing legal operations on them? Languages that have this property are called 'strongly typed'. Take a look at PHP, for instance, which is not strongly typed. You can use a variable to hold any value at all, regardless of the type of this value. This makes it easy to use, but it also makes it very easy for bugs to sneak into your code.

[Tom Brodhead]

Thanks...I actually understand why variables need to be declared; that's not the issue. There just seems to be a redundancy in the syntax when you have to say:

Apple x = new Apple();

...when it would seem more intuitive to do:

Apple() x;

...yes? Why have to state it twice? Ah, that's where this instantiation of an object as an child type seems to come in. Or at least that's what this notation supports. And that's where I'm still a bit confused.

If I code:

Fruit x = new Apple();

...is x a Fruit object now, or an Apple object?

[Seetharaman Venkatasamy]

@Tom : did you go through the link given by Stephan ?

<edit>
also please use code tag while posting your code, so that it can be easy to read.
</edit>

[Seetharaman Venkatasamy]

and Welcome to JavaRanch Tom

[Jesper de Jong]

Tom Brodhead wrote:...because Fruit() well might not have all of the properties of either Apple or Orange (am I right?)

Yes. Inheritance implies an "is a" relationship from the subclass to the superclass: an instance of the subclass is an instance of the superclass. For example, an Apple is a Fruit. But that relationship obviously doesn't hold the other way around; a Fruit is not always an Apple.

Tom Brodhead wrote:
But why would you do:

Fruit x = new Apple();

Because often the rest of the program should not care if x is specifically an Apple; it just needs to know that x is a Fruit. Stephan's post already explains that (click the link). Let's look at another example.

List<String> names = new ArrayList<String>();

Note that we're here declaring names as a List<String>, not as an ArrayList<String>. The rest of the program only needs to know that names is a list of strings - it does not need to know what specific implementation of interface List is used. That is good, because you might want to switch to another implementation. Suppose that you'd find out that a LinkedList would be more efficient in this case than an ArrayList. Then you'd only have to change one line of code:

List<String> names = new LinkedList<String>();

In the rest of the program, nothing would need to change, because names is still a List<String>. Had you declared names to be an ArrayList<String> directly, then other parts of the program might have been calling methods that are specific to ArrayList (and that do not exist in the List interface) and it would have been more work to change it.

One of the principles of object oriented design is to decouple parts of the program as much as possible, because too much coupling makes your program a hard to maintain interconnected mess - spaghetti code. One of the ways to minimize coupling is to let other parts of the program know only what they need to know, and not more. In the example above, the rest of the program only needs to know that names is a List<String>; it doesn't need to know what particular list implementation is used.

[Stephan van Hulst]

Tom Brodhead wrote:There just seems to be a redundancy in the syntax [...]

There is no redundancy. The declaration of the variable will tell the compiler what the type of the reference will be. Calling the constructor will tell the virtual machine what the runtime type is of the object referenced.

Apple x = new Apple() would only be redundant if Apples could only be referenced by variables of type Apple. This is not true. Apples can also be referenced by variables of type Fruit.

[fred rosenberger]

you also may have a collection of objects...something called fruitSaladIngredients. it contains Apples, Oranges, Grapes, Strawberries, etc.

you may want to iterate through the list, and wash() and slice() each ingredient. It's much easier to have a simple loop with one fruit reference that can in turn point to each object, than have a complicated if-else...

while <there are objects left>
   Fruit f = nextIngredient();
   f.wash();
   f.slice();

vs

while <there are objects left>
   if next object is a strawberry
      Strawberry s = nextIngredient();
      s.wash();
      s.slice();
   else if next object is apple
      Apple a = nextIngredient();
      a.wash();
      a.slice();
   else if next object is a grape...

Note that if someone decides to add a new fruit to your salad (i.e. honey dew melons), the first chunk of code DOES NOT NEED TO BE TOUCHED. In the second example, you have to add a whole new 'else-if' block. And if you later decide you need to also peel the fruit, in the first case you only need to add it in one spot. the second example you have to add it in each and every block - and it's possible there could be dozens if not hundreds of types...

[Mike Simmons]

Stephan van Hulst wrote:

Tom Brodhead wrote:There just seems to be a redundancy in the syntax [...]

There is no redundancy.

Mmmm, I think a lot of us still see redundancy here. Yes, the type of the reference and the type of the instance are different things - and as Fred shows, sometimes it's extremely useful for them to be different. The thing is, many times, it isn't - and we just type the same thing twice:

SomeReallyLongClassName foo = new SomeReallyLongClassName();

This is considered normal in Java, but that doesn't mean it isn't redundant. The Scala language for example allows users to omit many of these redundant declarations, while still retaining all the type information we're used to having in Java. The Scala version of this would be:

val foo = new SomeReallyLongClassName();

And the compiler just figures out that the type of reference foo is SomeReallyLongClassName. If you need the type to be something different, it's possible to specify that. But often you don't have to, and this works out just fine. With less verbosity.

Anyway, to Tom's question: yes, it's often redundant. But it's the way we do things in Java. And it's important to understand that the type of the reference and the type of the instance are not necessarily the same, and that sometimes this is an extremely useful distinction.

[Tom Brodhead]

Thanks for the very detailed help!

If I understand correctly, in:

Fruit x = new Apple();

...the LEFT side of the equation defines the REFERENCE type, while the RIGHT side of the equation defines the OBJECT type. (Yes?) This means that any object can have a reference type that is distinct from its object type.

So, the x.getClass() method would return the object type here: Apple. But is there a standard method that would return the reference type of an object?

[Stephan van Hulst]

No, an object doesn't have a reference type. An object knows nothing about the variable that references it. At runtime, the type of the reference is unimportant, it gets thrown away. It is only useful to the compiler.

Yes, x.getClass() will return the type of the object at runtime.

[Ralph Cook]

Something that may or may not help those struggling with the rules and regulations here that I think is good to keep in mind: the reference type, and also casting, never change the type of the object at runtime. You can declare reference to be Fruit, and/or you can cast it to Fruit, but it is always an Apple, and nothing in Java will change the object to be a different type.

Just for my 2 cents, I don't see the two mentions of the classname as redundant, I see it as consistent. When you instantiate an object, 'new' and a constructor reference is the way you do it. You do that whether or not it is on the same line as the declaration.

Humans see the same class name twice close together in an operation that is common in Java. Humans would be able to understand many things that would eliminate having to put them close together like that. But it would be a new syntax that the compiler, etc., would have to understand, and would increase the "clutter" of rules one would have to learn about Java.

I understand why people do see it as redundant, I'm just saying I'm glad this is the way it is.

rc

[Tom Brodhead]

I wrote the following to help me grasp the distinctions we're discussing. I'd be most interested in corrections to the comments I've made in the code, because my commentary will be my reference for understanding this in the future (it reveals what I do and don't understand about the code I've written.) Many thanks!

public class Stdout {
	public static void line(){
		System.out.println("");
	}
	public static void line(Object x){
		System.out.println(x);
	}	
}

public class Place extends Object {
	public void printMe() {
		Stdout.line("Place");
	}
}

public class Region extends Place {	
	public void printMe() {
		Stdout.line("Region");
	}	
}

public class State extends Region {
	public void printMe() {
		Stdout.line("State");
	}	
}

public class Maryland extends State {
	public void printMe() {
		Stdout.line("Maryland");
	}	
}

public class ObjectNameVsObjectFunction {
	
	public static void main(){
		
		// a, b, c, d are seen by the compiler as the type on the left
		// but behave as the type on the right:
		
		Object a = new Place();
		Place b = new Region();		
		Region c = new State();
		State d = new Maryland();
				
		// a now functions as Place(), but to the compiler
		// it looks like an Object type, which doesn't have a printMe() method.
		// Thus, cast it as Place and the compiler won't complain:
		((Place) a).printMe();
		
		// the rest compile without problem, because each stated type
		// has the printMe() method.  Upon execution, the functioning
		// printMe() method will be called:
		b.printMe();
		c.printMe();
		d.printMe();
				
		Stdout.line("----");
		
		// a can be set equal to b, c, d because they are subclasses of a.		
		// However, even though a is functioning as b, c, or d, it looks to
		// the compiler as an Object type and thus lacking a printMe() method.
		// So cast it as the type it's functioning as: 
		a = b;
		((Region) a).printMe();
		
		a = c;
		((State) a).printMe();
		
		a = d;
		((Maryland) a).printMe();
		
		Stdout.line("----");
		
		// b = a;
		// ...won't compile--can't set a class to function as a superclass
		
		b = c;
		b.printMe();
		
		b = d;
		b.printMe();
		
		Stdout.line("----");
		
		// c = a;
		// c = b;
		// ...won't compile--can't set a class to function as a superclass
		
		c = d;
		c.printMe();
		
		// d = a;
		// d = b;
		// d = c;
		// ...won't compile--can't set a class to function as a superclass
	}
}

[Jesper de Jong]

Looks like you understand the concepts!

Tom Brodhead wrote:...the LEFT side of the equation defines the REFERENCE type, while the RIGHT side of the equation defines the OBJECT type. (Yes?) This means that any object can have a reference type that is distinct from its object type.

The first sentence is more or less correct. Variables in Java are references to objects. Variables can have a type that is not the same as the type of the object they are referring to - for example, you can have a variable that has the type Fruit, while it's really referring to an object that has the type Apple.

The second sentence is incorrect. The object itself doesn't know anything about the variable that refers to it. In fact, multiple variables may refer to the same object:

// Three variables all referring to the same Apple object
Apple apple = new Apple();
Fruit fruit = apple;
Object object = apple;

The Apple object does not somehow keep track of the variables that refer to it.

It is not the object that has a "reference type" and an "object type" - an object has a type, and any variables that refer to it each have a type.