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?

  • 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?
    – user7433
    Mar 11, 2013 at 16:16
  • The different services execute as separate processes in the OS. They are all part of the same application.
    – c.hughes
    Mar 11, 2013 at 16:21
  • 13
    Only a sith deals in absolutes Mar 11, 2013 at 16:24
  • @TomSquires don't really understand your comment.
    – user7433
    Mar 11, 2013 at 16:45
  • @omouse - imdb.com/title/tt0121766/quotes, 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, 2013 at 17:32

3 Answers 3


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

  • Doesn't this design violate LSP in that you would need to add methods to GeneralObject each time a new derived object is created?
    – c.hughes
    Mar 11, 2013 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.
    – user7433
    Mar 11, 2013 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.

  • 1
    Well, const_cast exists in C++. And I don't think it is ever a good idea to cast constness away from an object.
    – c.hughes
    Mar 11, 2013 at 16:56
  • 3
    const_cast is useful when working with incorrect third party code you have no control over. Mar 11, 2013 at 17:39
  • Although I'm not sure if std::vector<bool> was a good idea, otherwise, I agree with you. Mar 12, 2013 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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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