Results 1 to 7 of 7
Like Tree1Likes
  • 1 Post By kjkrum

Thread: Book is wrong or I just don't get it...

  1. #1
    partsmutt is offline Member
    Join Date
    Jul 2013
    Posts
    2
    Rep Power
    0

    Default Book is wrong or I just don't get it...

    Hello all,
    I'm working through the 6th edition of Teach Yourself Java in 21 days and I've run across something that makes no sense to me. In day 3 (yes, confused at only day 3!) the author discusses casting objects. Here's the quote of confusion:

    *******

    The following example casts an instance of the class VicePresident to an instance of the class Employee. VicePresident is a subclass of Employee with more information:

    Employee emp = new Employee();
    VicePresident veep = new VicePresident();
    emp = veep; // no cast needed for upward use
    veep = (VicePresident) emp; // must cast explicitly

    ********

    The way I read this is that the comments on the last two lines of code are incorrect. emp is an Employee object, but references veep. But veep is a subclass which presumably will have more information and methods, so emp may be missing data. So the "upward use" comment seems wrong in my mind.

    In the last line the veep object is set as a reference to emp. If veep is a subclass of Employee anyway, doesn't it already have all the methods and data that emp contains? So why must emp be explicitly cast? Unless maybe the casting fills in the missing VicePresident data that veep expects?

    So I'll ramble just a little more here. In line 3, if the emp is referencing veep, emp will be missing information about veep, so shouldn't emp be cast?
    Like this: (VicePresident)emp = veep;

    Please set me straight or tell me I'm on the right track.
    Thanks
    Dave

  2. #2
    superhaNds is offline Senior Member
    Join Date
    Apr 2013
    Location
    Sweden
    Posts
    265
    Rep Power
    2

    Default Re: Book is wrong or I just don't get it...

    All VicePresidents are Employees, therefore, one can assign a vice president to an employee because it is an employee.
    On the other hand all Employees are not VicePresidents. The compiler sees that emp is not a VicePresident and one, by casting, promises the compiler that a VicePresident object will be assigned to emp.
    The cast puts a run time check to ensure that emp is assigned to a VicePresident object, and if at run time it is not a VicePresident, an exception is thrown.

  3. #3
    Toll's Avatar
    Toll is offline Senior Member
    Join Date
    May 2011
    Location
    Sweden
    Posts
    392
    Rep Power
    4

    Default Re: Book is wrong or I just don't get it...

    Look at it this way instead:

    VicePresident extends Employee, so you know it has all the functions Employee has (and some might be overridden etc). Thus, it's safe to cast it to an Employee object, because no matter what function you use on the Employee object, it'll still work since VicePresident has them all.

    The other direction, however, doesn't work. VicePresident might have some methods and data that Employee doesn't have, so what would happen if you cast Employee to VicePresident and tried using one of those methods/values? It wouldn't work very well, since the object doesn't actually have them.

    The reason you have to cast it explicitly is because it's entirely possible that some Employee objects are VicePresident objects. However, if the object you're trying to cast isn't one, that will throw an exception (I think it's ClassCastException, but I could be off on that one).

  4. #4
    kjkrum's Avatar
    kjkrum is offline Senior Member
    Join Date
    Apr 2011
    Location
    Tucson, AZ
    Posts
    1,060
    Rep Power
    6

    Default Re: Book is wrong or I just don't get it...

    You're thinking about it a bit wrong. Emp is not an employee object; emp is a reference to any object that extends Employee. It can refer to a VicePresident because a VicePresident is-a Employee. But there is no guarantee that emp points to VicePresident or any other particular subclass of Employee. The last line requires a cast because there's no guarantee that emp points to a VicePresident. It could point to a BeanCounter or a Janitor or any other kind of Employee. You know it refers to a VicePresident, but the compiler doesn't.
    Get in the habit of using standard Java naming conventions!

  5. #5
    partsmutt is offline Member
    Join Date
    Jul 2013
    Posts
    2
    Rep Power
    0

    Default Re: Book is wrong or I just don't get it...

    Thanks everyone. It took quite a while to digest this. In my mind (and maybe I'm wrong about this too - the book seems to be lacking in solid explanations) I was thinking that a float can't be cast to an int without losing information. A float is more digits and it has a fractional part. So I looked at the objects and was thinking the subclass has more information than the superclass, therefore cast sub to super would result in loss of information (just like a float to an int). I found the following definition on line that makes more sense than the book I'm using:

    "Subclass object can be assigned to a super class object and this casting is done implicitly. This is known as upcasting (upwards in the hierarchy from subclass to super class).

    Java does not permit to assign a super class object to a subclass object (implicitly) and still to do so, we need explicit casting. This is known as downcasting (super class to subclass). Downcasting requires explicit conversion.
    "

    If I knew the inner workings of the language it would probably make more sense to me. It still seems like the larger container of information (subclass) is being assigned to the smaller container (superclass). Which sounds lossy...but evidently isn't. I can live with "that's the way Java works" for now. I'm sure as I learn more and gain experience it will become clearer.
    Last edited by partsmutt; 07-14-2013 at 07:37 PM.

  6. #6
    Toll's Avatar
    Toll is offline Senior Member
    Join Date
    May 2011
    Location
    Sweden
    Posts
    392
    Rep Power
    4

    Default Re: Book is wrong or I just don't get it...

    Casting a class doesn't change what class it is. To copy the example above:

    Employee emp = new Employee();
    VicePresident veep = new VicePresident();
    emp = veep; // no cast needed for upward use
    veep = (VicePresident) emp; // must cast explicitly

    emp starts out as an Employee. Nothing more, nothing less.
    veep starts out as a VicePresident, which is a subclass of Employee.
    Here's the tricky part (at least for me to explain): emp = veep. Yes, emp is used as an Employee, but at that point, the object emp references is still a VicePresident. It doesn't lose any information, nor does it gain any. It's just... limited, I guess, to what Employees can do. This works, since VicePresidents can do everything Employees can. For instance, you can ask an Employee, any Employee, what its salary is, and even if that Employee is actually a VicePresident, it'd understand your request.
    veep = (VicePresident) emp; Here, we reverse it. This is only possible since emp is actually a VicePresident; had it been a normal Employee, it wouldn't have worked. For instance, say a VicePresident has access to a parking spot, which Employees don't. What would happen if you cast an Employee into a VicePresident object? All of a sudden you could ask it about its parking spot, but since it's not actually a VicePresident, it wouldn't have one.

  7. #7
    kjkrum's Avatar
    kjkrum is offline Senior Member
    Join Date
    Apr 2011
    Location
    Tucson, AZ
    Posts
    1,060
    Rep Power
    6

    Default Re: Book is wrong or I just don't get it...

    Quote Originally Posted by partsmutt View Post
    I was thinking that a float can't be cast to an int without losing information.
    You're right about that, but it's not quite analogous. The difference is that an int or float variable is just a value, but a reference variable points to an object that exists independently of the variable that refers to it. When you cast a float to an int, it may lose data; and if you cast it back to a float, you don't regain that lost data. But when you cast a reference variable, the object it refers to doesn't actually change. You just can't refer to parts of it that aren't part of the declared type of the variable by which you are referring to it.

    It's not uncommon to refer to the same object through several different variables. And they don't have to be subclass and superclass variables. If a class implements several unrelated interfaces, you could refer to an object of that class through variables of any of those types. The object itself would still have all the features of its actual class.
    Fubarable likes this.
    Get in the habit of using standard Java naming conventions!

Similar Threads

  1. Replies: 4
    Last Post: 06-11-2013, 01:37 AM
  2. Help with changing a Book Enum to a Book Class
    By Dragrain in forum New To Java
    Replies: 1
    Last Post: 12-06-2012, 07:18 PM
  3. I can't find anything wrong with this but somehow it's wrong.
    By Biscuit Tickler in forum New To Java
    Replies: 2
    Last Post: 09-12-2012, 09:28 PM
  4. ...? my text book is wrong?
    By elecleoalune in forum New To Java
    Replies: 17
    Last Post: 04-08-2011, 02:01 AM
  5. Is the Head First Java book wrong about Strings and GC?
    By raindog308 in forum New To Java
    Replies: 2
    Last Post: 02-07-2011, 10:05 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •