What is a proper use of downcasting?

Question

Downcasting means casting from a base class (or interface) to a subclass or leaf class.

An example of a downcast might be if you cast from System.Object to some other type.

Downcasting is unpopular, maybe a code smell: Object Oriented doctrine is to prefer, for example, defining and calling virtual or abstract methods instead of downcasting.

• What, if any, are good and proper use cases for downcasting? That is, in what circumstance(s) is it appropriate to write code that downcasts?
• If your answer is "none", then why is downcasting supported by the language?

Answer 1

Downcasting is unpopular, maybe a code smell

I disagree. Downcasting is extremely popular; a huge number of real-world programs contain one or more downcasts. And it is not maybe a code smell. It is definitely a code smell. That's why the downcasting operation is required to be manifest in the text of the program. It's so that you can more easily notice the smell and spend code review attention on it.

in what circumstance[s] is it appropriate to write code which downcasts?

In any circumstance where:

• you have a 100% correct knowledge of a fact about the runtime type of an expression that is more specific than the compile-time type of the expression, and
• you need to take advantage of that fact in order to use a capability of the object not available on the compile-time type, and
• it is a better use of time and effort to write the cast than it is to refactor the program to eliminate either of the first two points.

If you can cheaply refactor a program so that either the runtime type can be deduced by the compiler, or to refactor the program so that you don't need the capability of the more derived type, then do so. Downcasts were added to the language for those circumstances where it is hard and expensive to thus refactor the program.

why is downcasting supported by the language?

C# was invented by pragmatic programmers who have jobs to do, for pragmatic programmers who have jobs to do. The C# designers are not OO purists. And the C# type system is not perfect; by design it underestimates the restrictions that can be placed on the runtime type of a variable.

Also, downcasting is very safe in C#. We have a strong guarantee that the downcast will be verified at runtime and if it cannot be verified then the program does the right thing and crashes. This is wonderful; it means that if your 100% correct understanding of type semantics turns out to be 99.99% correct, then your program works 99.99% of the time and crashes the rest of the time, instead of behaving unpredictably and corrupting user data 0.01% of the time.

---

EXERCISE: There is at least one way to produce a downcast in C# without using an explicit cast operator. Can you think of any such scenarios? Since these are also potential code smells, what design factors do you think went into the design of a feature that could produce a downcast crash without having a manifest cast in the code?

Answer 2

Event handlers usually have the signature MethodName(object sender, EventArgs e). In some cases it's possible to handle the event without regard for what type sender is, or even without using sender at all, but in others sender must be cast to a more-specific type to handle the event.

For example, you may have two TextBoxs and you want to use a single delegate to handle an event from each of them. Then you would need to cast sender to a TextBox so that you could access the necessary properties to handle the event:

private void TextBox_TextChanged(object sender, EventArgs e)
{
   TextBox box = (TextBox)sender;
   box.BackColor = string.IsNullOrEmpty(box.Text) ? Color.Red : Color.White;
}

---

Yes, in this example, you could create your own subclass of TextBox which did this internally. Not always practical or possible, though.

Answer 3

You need downcasting when something gives you a supertype and you need to handle it differently depending on the subtype.

decimal value;
Donation d = user.getDonation();
if (d is CashDonation) {
     value = ((CashDonation)d).getValue();
}
if (d is ItemDonation) {
     value = itemValueEstimator.estimateValueOf(((ItemDonation)d).getItem());
}
System.out.println("Thank you for your generous donation of $" + value);

No, this does not smell good. In a perfect world Donation would have an abstract method getValue and each implementing subtype would have an appropriate implementation.

But what if these classes are from a library you can not or don't want to change? Then there is no other option.

Answer 4

Here are some proper uses of downcasting.

And I respectfully vehemently disagree with others here who say the use of downcasts is definitely a code smell, because I believe there is no other reasonable way to solve the corresponding problems.

Equals:

class A
{
    // Nothing here, but if you're a C++ programmer who dislikes object.Equals(object),
    // pretend it's not there and we have abstract bool A.Equals(A) instead.
}
class B : A
{
    private int x;
    public override bool Equals(object other)
    {
        var casted = other as B;  // cautious downcast (dynamic_cast in C++)
        return casted != null && this.x == casted.x;
    }
}

Clone:

class A : ICloneable
{
    // Again, if you dislike ICloneable, that's not the point.
    // Just ignore that and pretend this method returns type A instead of object.
    public virtual object Clone()
    {
        return this.MemberwiseClone();  // some sane default behavior, whatever
    }
}
class B : A
{
    private int[] x;
    public override object Clone()
    {
        var copy = (B)base.Clone();  // known downcast (static_cast in C++)
        copy.x = (int[])this.x.Clone();  // oh hey, another downcast!!
        return copy;
    }
}

Stream.EndRead/Write:

class MyStream : Stream
{
    private class AsyncResult : IAsyncResult
    {
        // ...
    }
    public override int EndRead(IAsyncResult other)
    {
        return Blah((AsyncResult)other);  // another downcast (likely ~static_cast)
    }
}

If you're going to say these are code smells, you need to provide better solutions for them (even if they are avoided due to inconvenience). I don't believe better solutions exist.

Answer 5

To add to Eric Lippert's answer since I can't comment...

You can often avoid downcasting by refactoring an API to use generics. But generics weren't added to the language until version 2.0. So even if your own code doesn't need to support ancient language versions, you may find yourself using legacy classes that aren't parameterized. For example, some class may be defined to carry a payload of type Object, which you're forced to cast to the type you know it to actually be.

Answer 6

There is a trade-off between static and dynamically typed languages. Static typing gives the compiler a lot of information to be able to make rather strong guarantees about the safety of (parts of) programs. This comes at a cost, however, because not only do you need to know that your program is correct, but you must write the appropriate code to convince the compiler that this is the case. In other words, making claims is easier than proving them.

There are "unsafe" constructs that help you make unproven assertions to the compiler. For example, unconditional calls to Nullable.Value, unconditional downcasts, dynamic objects, etc. They allow you to assert a claim ("I assert that object a is a String, if I'm wrong, throw a InvalidCastException") without needing to prove it. This can be useful in cases where proving it is significantly harder than worthwhile.

Abusing this is risky, which is exactly why the explicit downcast notation exists and is mandatory; it's syntactic salt meant to draw attention to an unsafe operation. The language could have been implemented with implicit downcasting (where the inferred type is unambiguous), but that would hide this unsafe operation, which is not desirable.

Answer 7

Downcasting is considered bad for a couple of reasons. Primarily I think because it's anti-OOP.

OOP would really like it if you never ever had to downcast as its ''raison-d'etre'' is that polymorphism means you don't have to go

if(object is X)
{
    //do the thing we do with X's
}
else
{
    //of the thing we do with Y's
}

you just do

x.DoThing()

and the code auto-magically does the right thing.

There are some 'hard' reasons not to downcast:

• In C++ it is slow.
• You get a runtime error if you choose the wrong type.

But the alternative to downcasting in some scenarios can be pretty ugly.

The classic example is message processing, where you don't want to add the processing function to the object, but keep it in the message processor. I then have a tonne of MessageBaseClass in an array to process, but I also need each one by subtype for correct processing.

You can use Double Dispatch to get around the problem (https://en.wikipedia.org/wiki/Double_dispatch)... But that also has its issues. Or you can just downcast for some simple code at the risk of those hard reasons.

But this was before Generics were invented. Now you can avoid downcasting by providing a type where the details specified later.

MessageProccesor<T> can vary its method parameters and return values by the specified type but still provide generic functionality

Of course no-one is forcing you to write OOP code and there are plenty of language features that are provided but frowned upon, such as reflection.

Answer 8

In addition to all before said, imagine a Tag property that is of type object. It provides a way for you to store an object of your choice in another object for later use as you need. You need downcast this property.

In general, not using something until today is not always an indication of something useless ;-)

Answer 9

The most common use of downcasting in my work is due to some idiot breaking Liskov’s Substitution principle.

Imagine there’s an interface in some third party lib.

public interface Foo
{
     void SayHello();
     void SayGoodbye();
 }

And 2 classes that implement it. Bar and Qux. Bar is well behaved.

public class Bar
{
    void SayHello()
    {
        Console.WriteLine(“Bar says hello.”);
    }
    void SayGoodbye()
    {
         Console.WriteLine(“Bar says goodbye”);
    }
}

But Qux isn’t well behaved.

public class Qux
{
    void SayHello()
    {
        Console.WriteLine(“Qux says hello.”);
    }
    void SayGoodbye()
    {
        throw new NotImplementedException();
    }
}

Well... now I don’t have a choice. I have to type check and (possibly) downcast in order to avoid having my program come to a crashing halt.

Answer 10

Another real-world example is WPF's VisualTreeHelper. It uses downcast to cast DependencyObject to Visual and Visual3D. For example, VisualTreeHelper.GetParent. The downcast happens in VisualTreeUtils.AsVisualHelper:

private static bool AsVisualHelper(DependencyObject element, out Visual visual, out Visual3D visual3D)
{
    Visual elementAsVisual = element as Visual;

    if (elementAsVisual != null)
    {
        visual = elementAsVisual;
        visual3D = null;
        return true;
    }

    Visual3D elementAsVisual3D = element as Visual3D;

    if (elementAsVisual3D != null)
    {
        visual = null;
        visual3D = elementAsVisual3D;
        return true;
    }            

    visual = null;
    visual3D = null;
    return false;
}