向下转换的正确用法是什么？

向下转换意味着从基类（或接口）转换为子类或叶类。

如果您从转换System.Object为其他类型，则可能会导致沮丧。

向下转换不受欢迎，可能有代码味道：例如，面向对象的理论更喜欢定义和调用虚拟或抽象方法，而不是向下转换。

• 什么是向下转换的好用例（如果有）？也就是说，在什么情况下编写向下转换的代码是合适的？
• 如果您的答案为“无”，那么为什么该语言支持向下转换？

这是向下转换的一些正确用法。

我在此强烈地不同意其他人的意见，他们说使用向下转换绝对是一种代码味道，因为我相信没有其他合理的方法可以解决相应的问题。

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)
    }
}

如果您要说这些是代码异味，则需要为它们提供更好的解决方案（即使由于不便而避免使用它们）。我认为没有更好的解决方案。

垂头丧气是不受欢迎的，也许是代码气味

我不同意。垂头丧气非常流行 ; 大量的现实世界节目包含一个或多个向下转换。而且这可能不是代码的味道。这是绝对一个代码味道。 这就是为什么要求向下转换操作必须在程序文本中显示的原因。这样一来，您可以更轻松地注意到气味，并花费代码对其进行关注。

在什么情况下编写向下转换的代码合适？

在任何情况下：

• 您对表达式的运行时类型的事实有100％的正确认识，该事实比表达式的编译时类型更具体，并且
• 您需要利用这一事实，以使用编译时类型上不可用的对象功能，并且
• 与重构程序以消除前两点中的任何一个相比，更好地利用时间和精力来编写演员表。

如果您可以廉价地重构程序，以便可以由编译器推断运行时类型，或者可以重构程序以使您不需要更多派生类型的功能，则可以这样做。对于那些难以重构程序且昂贵的情况，在语言中添加了向下转换。

语言为何支持向下转换？

C＃是由谁有工作做，务实的程序员发明了谁有工作做务实的程序员。C＃设计人员不是面向对象的纯粹主义者。而且C＃类型系统并不完美；通过设计，它低估了可以对变量的运行时类型施加的限制。

同样，向下转换在C＃中非常安全。我们有力保证将在运行时对向下转换进行验证，如果无法对其进行验证，则程序将执行正确的操作并崩溃。这太好了；这意味着，如果您对类型语义的100％正确理解是99.99％正确，那么您的程序将在99.99％的时间内工作，并在其余时间崩溃，而不是行为异常并在0.01％的时间内破坏用户数据。

练习：至少有一种方法可以在不使用显式强制转换运算符的情况下用C＃产生下调。您能想到任何这种情况吗？由于这些也是潜在的代码异味，因此您认为在设计功能时会导致向下崩溃而没有在代码中强制转换的设计因素是什么？

事件处理程序通常具有签名MethodName(object sender, EventArgs e)。在某些情况下，可以处理事件而无需考虑是什么类型sender，甚至根本不使用sender任何类型，但是在其他情况下，sender必须将其转换为更特定的类型来处理事件。

例如，您可能有两个，TextBox而您想使用一个委托来处理每个事件。然后，您需要强制sender转换为，TextBox以便您可以访问必要的属性来处理事件：

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

是的，在此示例中，您可以创建自己的子类，TextBox该子类在内部完成。但是，并非总是可行或不可能的。

当某些东西给您一个超类型时，您需要向下转换，并且您需要根据子类型来不同地处理它。

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);

不，这闻起来不好。在理想情况下，Donation将有一个抽象方法，getValue并且每个实现子类型都将具有一个适当的实现。

但是，如果这些类是来自某个库的，您无法更改或不想更改该怎么办？然后没有其他选择。

由于我无法发表评论，因此请添加到埃里克·利珀特的答案中 ...

您通常可以通过重构API以使用泛型来避免低估。但是直到2.0版才向语言中添加泛型。因此，即使您自己的代码不需要支持古代语言版本，您也可能会发现自己使用未参数化的旧类。例如，可能定义了一些类来承载type的有效负载Object，您必须将其强制转换为您真正知道的类型。

在静态和动态类型的语言之间需要权衡取舍。静态类型为编译器提供了大量信息，从而可以对程序（部分）的安全性做出相当有力的保证。但是，这是有代价的，因为您不仅需要知道您的程序是正确的，而且还必须编写适当的代码以使编译器确信这种情况。换句话说，提出索赔要比证明它们容易。

有“不安全”的构造可以帮助您对编译器进行未经证实的断言。例如，无条件调用Nullable.Value，无条件下调，dynamic对象等。它们使您可以声明要求（“我断言对象a是a String，如果我错了，则抛出InvalidCastException”），而无需证明它。在证明它比值得证明困难得多的情况下，这很有用。

滥用它是有风险的，这正是为什么存在明显的向下标记表示法并且是强制性的原因。它是一种语法盐，旨在引起人们对不安全操作的注意。该语言本可以通过隐式向下转换来实现的（其中推断的类型是明确的），但这将隐藏这种不安全的操作，这是不希望的。

向下转换被认为是不好的，原因有两个。我主要认为是因为它是反面向对象的。

OOP真的很喜欢它，如果您再也不需要丢脸的话，它的“存在理由”就是多态意味着您不必走下去

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

你只是做

x.DoThing()

并且代码自动神奇地完成了正确的事情。

有一些不容忽视的“硬”原因：

• 在C ++中，它很慢。
• 如果选择错误的类型，则会出现运行时错误。

但是在某些情况下替代向下转换的方法可能非常丑陋。

经典示例是消息处理，您不想在对象上添加处理功能，而是将其保留在消息处理器中。然后MessageBaseClass，我要在阵列中处理一吨，但我还需要每个子类型按正确处理。

您可以使用Double Dispatch来解决问题（https://en.wikipedia.org/wiki/Double_dispatch）...但这也有问题。或者，您也可以因为一些困难的原因而放弃一些简单的代码。

但这是在泛型发明之前。现在，您可以通过提供一种在以后指定详细信息的类型来避免向下转换。

MessageProccesor<T> 可以按指定类型更改其方法参数和返回值，但仍提供通用功能

当然，没有人会强迫您编写OOP代码，并且提供了许多语言功能，但令人反感，例如反射。

除了前面提到的所有内容外，还可以想象一个对象类型为Tag的属性。它为您提供了一种将所选对象存储在另一个对象中，以便以后根据需要使用的方法。您需要将此属性下调。

总的来说，直到今天不使用某些东西并不总是表明某些东西无用;-)

在我的作品中，垂头丧气最常见的用法是由于某些白痴违反了Liskov的“替代原则”。

想象一下某个第三方库中有一个接口。

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

还有两个实现它的类。Bar和Qux。Bar表现得很好。

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

但是Qux表现不佳。

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

好吧...现在我别无选择。为了避免程序崩溃，我必须输入check和（可能）向下转换。

另一个真实示例是WPF的VisualTreeHelper。它使用向下转换来投射DependencyObject到Visual和Visual3D。例如，VisualTreeHelper.GetParent。失败发生在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;
}