aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes downcasting in implementation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "downcasting in implementation" Watch "downcasting in implementation" New topic
Author

downcasting in implementation

Mohit Sinha
Ranch Hand

Joined: Nov 29, 2004
Posts: 125
Hi All,

I want to understand if it is a good or common practice to use downcasting in the implementation. I have a Type class which has some common behavior. Then we have flavors of this Type class. For brevity sake I will address them as Light, Medium and Heavy.
Light apart from inheriting the derived implementation will also have some custom behavior specific to Light. The same holds true for Medium and Heavy.

We have exposed the generic "Type" as an input parameter. Now the invoking program can pass Light , Medium or Heavy wrapped inside "Type" object reference. (Type t = new Light())
To invoke the specific custom implementation as mentioned above I will have to downcast the Type object reference (Light l = (Light)t)
Is this a common practice to use.

Regards,




Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
It is sometimes the best you can do, but most often it's better to make use of polymorphism.

How will you know what type to cast to?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Mohit Sinha
Ranch Hand

Joined: Nov 29, 2004
Posts: 125
---------------------------------------------
How will you know what type to cast to?
---------------------------------------------
based on the instanceOf operator output we plan to take appropriate action.




Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Ok, so that's a bigger concern. This is typically called a "type case", and by many regarded a code smell.

The problem is that it makes the code more rigid by violating the Single Choice Principle - every time you add another type to the code base, you will potentially need to touch any such type case to add the additional type. This makes changes very laboursome and prone to bugs.

The typical solution is to use polymorphism instead. Can you tell us more about how the implementations for the different types would differ? Perhaps with an example?
Mohit Sinha
Ranch Hand

Joined: Nov 29, 2004
Posts: 125
Ok. To give the scenario we have is the parent (Type class) has all generic behavior for all possible product types.
Per the design each of these product types have specific instance variables.
so accordingly Light will have specific variables (spInd, fdInd) and it will have methods operating on these variables.
Now Medium type has its own set of such specific variables which make no sense to type:Light.

There is businessProcessor class where all further calculations take place. To make the object model strictly representing the real world business objects we kind of arrived at this structure. Now in the businessProcessor class it becomes inevitable for us to decipher what is the sub type (light,medium or heavy) so we grab all the appropriate input passed along via the Type object.

Thanks!


Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Mohit Sinha wrote:
There is businessProcessor class where all further calculations take place. To make the object model strictly representing the real world business objects we kind of arrived at this structure. Now in the businessProcessor class it becomes inevitable for us to decipher what is the sub type (light,medium or heavy) so we grab all the appropriate input passed along via the Type object.


The simplest *object oriented* solution to your problem would be to move the parts of the calculations that are specific to the different types into the Type objects. http://www.pragprog.com/articles/tell-dont-ask

What would happen if you did that?
Mohit Sinha
Ranch Hand

Joined: Nov 29, 2004
Posts: 125
Thanks Ilja. Your point is well taken.

But this brings another question in my mind. Aren't child objects in an inheritance free to have their own specific methods. The knowledge of these new implementations will never be known parent and will throw an error when trying to access new methods of the child object via a parent object reference.
Are you saying child classes should only stick to overriding and not have new methods.

Is downcasting something to be avoided all the time. How can a downcasting scenario be handled differently.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Mohit Sinha wrote:
But this brings another question in my mind. Aren't child objects in an inheritance free to have their own specific methods. The knowledge of these new implementations will never be known parent and will throw an error when trying to access new methods of the child object via a parent object reference.
Are you saying child classes should only stick to overriding and not have new methods.


No, I'm not saying that. Sometimes you actually *do* have a reference to the actual type (instead of the parent type), in which case calling methods specific to the single implementation is no problem at all.


Is downcasting something to be avoided all the time. How can a downcasting scenario be handled differently.


In fact, it's not downcasting that's the problem. It's the type check that may come before it. Especially if you have many of them.

The main question you should ask yourself is: "what would happen if I introduced another subtype?" If the answer is "I would have to check for that type and introduce another down cast", look for another solution. One that doesn't violate the Open Closed Principle. That solution will likely make use of some form of polymorphism.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: downcasting in implementation