Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

At my company, we have many different "services" that work in parallel and send messages to each other using a common messaging system. All message objects are derived from a common generic object we defined for messaging. When any service receives a message, the first thing it must do is downcast the object to the derived type so that it can extract the data needed.

I have read all over the internet that you should not have to downcast a base object pointer to a derived object pointer and that having to do this is often a sign of bad design. I agree with this sentiment for most cases. And I can imagine different designs for the generic message object that wouldn't necessitate down-casting. But I don't see any big reason to handle this situation differently.

So my overall question is: Is down-casting always a bad thing? Are there situations in which down-casting is necessary or acceptable?

share|improve this question
Downcasting a pointer vs making a generic payload into a specific object are two different things. Are the services actually different processes that communicate or is it all within the same program? – omouse Mar 11 '13 at 16:16
The different services execute as separate processes in the OS. They are all part of the same application. – Mar 11 '13 at 16:21
Only a sith deals in absolutes – Tom Squires Mar 11 '13 at 16:24
@TomSquires don't really understand your comment. – omouse Mar 11 '13 at 16:45
@omouse -, slightly under halfway down the page. In this context, it means that there's no "always true in every possible case" rule - everything has an exception where it's worth doing. – Bobson Mar 11 '13 at 17:32
up vote 9 down vote accepted

Downcasting a pointer vs making a generic payload into a specific object are two different things.

The common messaging system API should have a set of functions for returning the exact object you want so that you aren't constantly downcast in your application code (which is more error-prone).

You're basically talking about passing around objects using XML or JSON or some other data interchange format. Talking about downcasting is unnecessary because it should already be handled by the common messaging system API since you know exactly what sorts of objects are being passed around.

I'm assuming the system API looks like this:

GeneralObject* getObject(Message *message);

It should look like this:

GeneralObject* _getObject(Message *message); // the _ is just to indicate this is a private function that shouldn't be used outside of this module

// these raise exceptions if the object doesn't exist or return null or whatever
Person* getPerson(Message *message);
Place* getPlace(Message *message);

Never in your code will you use the generic function that returns the base class, you'll always use the code that returns the derived classes and let the API handle or raise errors if it can't downcast.

Downcasting in this case is basically failing to parse or de-serialize an object.

Google's protobuf library has an example of what I'm talking about

share|improve this answer
Doesn't this design violate LSP in that you would need to add methods to GeneralObject each time a new derived object is created? – Mar 11 '13 at 16:53
GeneralObject should be renamed to SerializableObject or something and its purpose will be clear. I don't think you need to add the getPerson and getPlace methods to the GeneralObject class, but it doesn't matter much. You know exactly what kinds of objects you're passing around, at some point they're going to be downcast. The LSP is violated only if you're thinking about the code in a particular way. If you want to substitute a Person for a Place, that's no good. if you want to substitute them when creating the message using the System API, that's okay. – omouse Mar 11 '13 at 17:03

Obviously, if it were always a bad thing, there would be no need for the language to even support the operation. Serialization/messaging is one big exception, because the downcast generally greatly simplifies the code, although you should really build the cast into the message queue object. Templates are often useful in that case.

The other situation I've seen where downcasts are often unavoidable is in equals(Object obj) overrides, since that specific signature is part of a published, widely-used interface.

share|improve this answer
Well, const_cast exists in C++. And I don't think it is ever a good idea to cast constness away from an object. – Mar 11 '13 at 16:56
const_cast is useful when working with incorrect third party code you have no control over. – Karl Bielefeldt Mar 11 '13 at 17:39
Although I'm not sure if std::vector<bool> was a good idea, otherwise, I agree with you. – Christopher Creutzig Mar 12 '13 at 6:36

Yes, downcasting is always bad. Yes, occasionally you will run into scenarios (like messaging constructs) where the alternatives are worse.

And of course "worse" is subjective. In some scenarios, the fragility of down casting is very unacceptable. In others, simplicity of design or readability might have higher priority. Like any other design decision, it is a trade-off you'll need to evaluate for your situation.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.