Let's say you have a reference to an object in memory, but the reference type is something like <CODE>java.lang.Object</CODE>. Not real useful if you want specific behavior from the actual thing in memory: let's say it's really a <CODE>java.awt.Button</CODE> object). So you'd normally just run something like: <CODE>Button btn = (Button)objThing;</CODE> to get a Button reference back. Now: let's say that all you know about objThing is that it's a subclass of <CODE>java.awt.Component</CODE>. You'd like to figure out what class it specifically belongs to at runtime, then apply that knowledge "dynamically" to perform the downcast. In other words, you want to replace the casting directive <CODE>(Button)</CODE> above with the more general instruction (cast to whatever subclass we found). We can get the information at runtime; that's no problem. What we can't do is use it inside a casting operator; there's no provision for it. I haven't gone looking for the technical justification in print, but I can imagine it. In short, the type safety Java wants to enforce would be jeopardized by allowing the programmer to declare "no particular type at the moment" in a downcast operation. Actually, the compiler wouldn't stand for it. You can simulate the effect, but it's not trivial to do so. Furthermore, in order to make it work, you still have to agree somewhere at compile-time on a common type. Fully dynamic downcasting isn't possible under those circumstances. ------------------ Michael Ernest, co-author of: The Complete Java 2 Certification Study Guide [This message has been edited by Michael Ernest (edited January 10, 2001).]
I've come up with a situation where I have to do an instanceof check before doing a downcast to a particular class. Is it true that a situation like this indicates a flaw in the design of the system ? Is there a way I can do a dynamic downcast without any "if's" [ March 19, 2004: Message edited by: V Bose ]
Think you're out of luck. When you down cast it, you want to assign it to a variable. What type would you make the variable? When you have the "if" tests you can assign it to a variable of exactly the type you need.
What would the code look like to dynamic cast?
I couldn't guess what type to use. You asked if "instanceof" was a warning sign in design. It can be. It means that if you pass a new type of argument to a method you have to open up and modify the method. Not a big deal in a one-person project with a half dozen classes. But it can be a huge deal in a big project. There is some risk every time you open up a class and modify a method that you'll break something else. It can mean an expensive cycle of build and regression testing. It's good to isolate change. If I change the type of the argument do I also have to change the method? That's not ideal, fer sure. The theory on all this gets advanced in a hurry so I'm not going to elaborate in this forum, but it is based on reality and experience, not ivory tower imaginings. One day it will be worth studying up on. Visit the OO, UML, etc. forum further down the page if you want to get feet wet.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
I've come up with a situation where I have to do an instanceof check before doing a downcast to a particular class. Is it true that a situation like this indicates a flaw in the design of the system ? The "instanceof" operator exists for a good reason. Sometimes you just need it. You just have to be a little careful because it's often abused. Just be aware of the polymorphic alternative and choose the right option for the specific problem you're trying to solve (in particular if you don't have the ability to modify a certain class but want special behavior for it, you'll usually need an instanceof check).