How to tell if it's a String

[Loren Agular]

I'm reading off a google spreadsheet.
I thought a certain value was a string.
So I did: boolean b = row.get(0) instanceof String;
And this returned true.
However when I tried to pass the value to a constructor of another class it said it wasn't a String but a object.
And sure enough I looked up at the given code in the API and found: List<List<Object>>

Why did the boolean return true if it's not a String but a generic object?

Thanks

[Carey Brown]

A String is an Object. An Object may or may not be a String. If you try to pass an Object to a method expecting a String it won't work because it might not be a String. IF you KNOW it's a String, then you could cast the Object to a String when calling the method.

[Loren Agular]

Carey Brown wrote:A String is an Object. An Object may or may not be a String. If you try to pass an Object to a method expecting a String it won't work because it might not be a String. IF you KNOW it's a String, then you could cast the Object to a String when calling the method.

Thanks I think I understand that.
I already casted it for my purposes.
But my question was how to tell if the object is a string?
Because as I stated in the OP, the "instanceof String" returned true but it was a generic object.
Because a String is most specific than a Object, shouldn't it have returned false?
What I mean is how can one verify that you have a generic object instead of a string?

[Jesper de Jong]

The row.get(...) method returns a java.lang.Object - that's just how the method is designed. You can look it up in the API documentation, and you'll see that it returns an Object.

But that object could be anything at runtime, it could be a String, or some other kind of object. You already know how to check if it's a String - by using instanceof. Once you know it's a String, you can cast it to the type String, so that you can work with it.

For example:

Object value = row.get(0);
if (value instanceof String) {
    String text = (String) value;  // Cast it to a String

	// Now you can work with the variable 'text' which is a String
	System.out.println("Found a string: " + text);
}

Glenn Jayasuriya wrote:But my question was how to tell if the object is a string?

By using instanceof.

Glenn Jayasuriya wrote:Because as I stated in the OP, the "instanceof String" returned true but it was a generic object.
Because a String is most specific than a Object, shouldn't it have returned false?

The return type of the row.get(...) method is Object, but the object that it returned was really a String. Remember, class String extends Object, so a String is also an Object. When a method says it returns Object, then that object can at runtime be any kind of object. In this case it was a String.

Glenn Jayasuriya wrote:What I mean is how can one verify that you have a generic object instead of a string?

There's not really such a thing as a "generic object". (What exactly do you mean by that?). If it's something else than a String then value instanceof String would return false.

If you have a variable that's of type Object and you want to know what the exact kind of Object it's referring to, then you can show the class name like this:

Object value = ...;

System.out.println("value refers to an object of this type: " + value.getClass().getName());

[Loren Agular]

Thank you for your through explanation I get it now.
Had to review child classes but I get now that the parent class can contain an instance of a child class and at runtime acts like a String.
Thanks so much for clarifying!

[Junilu Lacar]

I'm not really sure what type of object that row variable refers to but when you start using instanceof in code that's not part of a utility library, that's a code smell. When you have to resort to using instanceof in regular application code, then you're probably doing something terribly wrong from a design and clean code perspective.

[Jesper de Jong]

To make sure you use the correct terms, which also makes it easier to understand: make sure you understand the difference between a variable, a class and an object.

A class is a description (a bluepint) that defines what objects of that class look like. You define classes by writing Java code. For example, you could have a class House, which defines what constitutes a House. Then you can create objects of class House.

One of the tools you can use to define classes is inheritance, where you can declare classes that are based on other classes. It's important to understand what inheritance actually means - it means specialization, so a subclass is a special kind of its superclass. You could for example have a class Villa that extends class House - a Villa is a special kind of House. You can have objects of type Villa, which are (of course) also Houses.

A variable is a holder for a value; that value can be a reference to an object. Variables have a type, which restricts the kinds of values that the variable can hold. The type of a variable is a class* and the type of the variable restricts the possible values of the variable. For example, a variable of type House can refer to a House object, or an object of a subclass of House. Why can it also refer to an object of a subclass of House? Because any object of a subclass of House, for example a Villa object, is also a House - because inheritance means specialization (see above). So, anything you can do with a House, you can also do with a Villa, and therefore it's safe to treat a Villa as being a House. This is called the Liskov substitution principle

*: except for variables of primitive types: int, short, long, byte, float, double, char, boolean

Now, with the knowledge, let's get your terminology straight:

Glenn Jayasuriya wrote:Had to review child classes but I get now that the parent class can contain an instance of a child class and at runtime acts like a String.

What you really meant to say was: A variable of a superclass type can refer to an object of a subclass type.

You can have a variable (not a class - variables and classes are different concepts) of a superclass type (what you call "parent class") and it can refer to an object that is of a subclass of that type. That object is an instance of the subclass type (it doesn't "act like" it, it is of that type).

[Loren Agular]

Ok I'm trying to understand.

Is there a difference between the word parent class and superclass? Child class and subclass?
From my understanding there really isn't much of a difference.
And i think in javadocs it says they are the same thing: https://docs.oracle.com/javase/tutorial/java/IandI/subclasses.html

Also isn't an object just a instance of a class?
So "object of a subclass type" is really an instance of subclass which is an instance of a child class which is what i wrote.
But I understand your point about a variable of a superclass/parent class and not the class itself.

[Junilu Lacar]

The difference is semantics. There is a certain connotation that comes with calling the relationship as a Parent/Child relationship versus saying Superclass/Subclass. The nuance is not that evident when you use super/sub though.  I actually prefer to follow up by saying that super/sub connotes a Generalization/Specialization relationship.  That is, a superclass is a generalization of its subclasses. Conversely, subclasses are specializations of their superclass.

In that way, you can get away from the things that your brain does when it hears "Parent/Child" that often mislead you when it comes to thinking about an object-oriented design. Generalization/Specialization is a more appropriate way of viewing a superclass/subclass relationship.

[Junilu Lacar]

Take Object, List, and String, for example. List and String are both subclasses of Object. However, they belong to different type hierarchies and a List cannot be used where a String is expected. An ArrayList can be used where a List is expected because an ArrayList is a subclass of List. In other words, you can use an ArrayList instead of List because an ArrayList is just a special kind of List and while it is special, it will still do everything that a generic List can be expected to do.

So, when you declare a thing as an Object, you can make any object, a String or a List or whatever, stand in that place in the code and reasonably expect it to behave just as any other Object should behave. Except you can't expect it to behave like a List because not all Objects are Lists and the code is only expecting behaviors based on the general definition of how an Object behaves, not the specific definition of how a List behaves.

I hope that makes sense and clears a few things up rather than muddy the waters for you even more.

[Jesper de Jong]

Glenn Jayasuriya wrote:Is there a difference between the word parent class and superclass? Child class and subclass?
From my understanding there really isn't much of a difference.

That's right, "parent class" and "superclass" mean the same thing, and "child class" and "subclass" also mean the same. I don't like the words "parent" and "child" here though. People use these words because it is about the OO programming feature that we call "inheritance", but using the words "parent" and "child" confuses the OO programming meaning of that word with the biological meaning.

Since people are already familiar with the biological meaning of the word, they think they already know what "inheritance" means when they encounter it in OO programming, but they really don't. In programming, inheritance means specialization, and it implies that there is a "is a (special kind of)" relationship between the subclass and the superclass. But this is not true in biology. If you create a class Parent and a class Child extends Parent, then what you are saying is: "a Child is a special kind of Parent". Which is of course not correct. So, I wish people would avoid the use of "parent" and "child" class when talking about programming.

Glenn Jayasuriya wrote:Also isn't an object just a instance of a class?
So "object of a subclass type" is really an instance of subclass which is an instance of a child class which is what i wrote.

Yes, objects are instances of classes, so another way to say "object of a subclass type" is indeed "instance of a subclass".

In my opinion it's important to be precise with terminology, because it will make it easier to understand exactly what all the terms mean and how they fit together.