hi every body I just want to know what happen when we do an casting in object does it change in it structure or in it values ???
ex: suppose fruit is object of super class Fruit and apple is object of sup class Apple what happen if we do that
fruit = apple //this an implict casting it same fruit = (Fruit)apple;
Object is generic
Fruit is less generic, some what specific
Apple is more specific
when you refer Apple as Object ... you can only know that its an object and its having a hashcode
when you refer Apple as Fruit ... you know that its an Apple and may know if its a seeded fruit or jello type depending on the properties of the class Fruit
when you refer Apple as Apple ... you know that its an Apple and if its a seeded fruit or jello type and you may calculate its nutrient values using its own methods
Basically, nothing in structure changes... but it depends on what you can see from your point. Programatically, if the referring class has a property / method of same type and signature and it is one of the parent classes of the assigned object, it can access the assigned objects property / method.
maary bill wrote:hi every body I just want to know what happen when we do an casting in object does it change in it structure or in it values ???
Casting one reference type to another reference type does not do any kind of conversion. So no, it does not change the structure or the value of what you are casting.
Casting is nothing more than telling the compiler that you know better than the compiler what the actual type of an object is. Suppose that you have a class Fruit and a subclass Apple. Somewhere in your code, you create an Apple like this:
You can do this without a cast because an Apple is a Fruit (Apple is a subclass of Fruit).
Suppose that later on in the program you need to access some specific method of class Apple on todaysFruit, and you happen to know that todaysFruit is really an Apple, even though the type of the variable is Fruit and not Apple. You could then cast it:
What you are doing here is telling the compiler: "I have something here that you think is a Fruit, but I know that it is an Apple, so treat it as if it is an Apple." Note that the check if it really is an Apple is still done at runtime; so when you run the program and Java notices that the object is in fact not an Apple, you will get a ClassCastException.
So, a cast defers a type check from compile time to runtime. You are giving up some of the type safety that the compiler provides. In principle you should avoid casts as much as possible because of this. The less casts you have, the less chance that your program will crash with an unexpected ClassCastException.
With primitive types, casting works a little differently; primitive types are indeed converted when you do a cast. For example when you cast a float to an int, the value of the float is converted to an integer (and you loose the digits after the decimal point).
It's exactly what Jesper just told you. You're telling the compiler, "Even though you know o1 as type Object, I want you to treat it as Comparable." The compiler allows it because it's possible the object could be a Comparable. (Remember implementing an interface is inheritance, and it's an IS-A relationship, just like extending a class.) And it's fine at runtime if the object pointed to actually happens to BE a Comparable.
So what are you not understanding?
Joined: Jun 20, 2011
If you want to know how to use the references, read on, you know that every class inherits Object class. The problem is Object class is too generic to use in a real app. So you create classes according to your need. Now, since Object class is a parent class of your "created classes", you can refer the objects of your classes (the app classes you have created) with Object class reference. But Object class doesn't know any of the new properties in your app class. So you must use a reference that knows more about your app class object to refer the property. That's where the casting comes into picture. You cast the object into a more specific type to pickup the properties in it. Same applies to methods too.