¿Cuál es el uso adecuado de la abatición?

Downcasting significa transmitir desde una clase base (o interfaz) a una subclase o clase hoja.

Un ejemplo de abatido podría ser si realiza un envío desde System.Objectotro tipo.

Downcasting es impopular, tal vez un olor a código: la doctrina orientada a objetos es preferible, por ejemplo, definir y llamar a métodos virtuales o abstractos en lugar de downcasting.

• ¿Cuáles son, si los hay, casos de uso adecuados y adecuados para la conversión? Es decir, ¿en qué circunstancia (s) es apropiado escribir código que no sea válido?
• Si su respuesta es "ninguna", entonces ¿por qué el idioma admite el downcasting?

Estos son algunos de los usos adecuados del downcasting.

Y con todo respeto vehementemente en desacuerdo con otros aquí que dicen que el uso de downcasts es sin duda un olor código, porque creo que no hay otra forma razonable de resolver los problemas correspondientes.

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

Si va a decir que estos son olores de código, debe proporcionar mejores soluciones para ellos (incluso si se evitan por inconvenientes). No creo que existan mejores soluciones.

Downcasting es impopular, tal vez un olor a código

Estoy en desacuerdo. Downcasting es extremadamente popular ; Una gran cantidad de programas del mundo real contienen uno o más programas descartados. Y tal vez no sea un olor a código. Definitivamente es un olor a código. Es por eso que se requiere que la operación de downcasting se manifieste en el texto del programa . Es para que pueda notar más fácilmente el olor y dedicar atención a revisar el código.

¿En qué circunstancias es apropiado escribir código que no sea válido?

En cualquier circunstancia donde:

• tiene un conocimiento 100% correcto de un hecho sobre el tipo de tiempo de ejecución de una expresión que es más específico que el tipo de tiempo de compilación de la expresión, y
• necesita aprovechar ese hecho para utilizar una capacidad del objeto no disponible en el tipo de tiempo de compilación, y
• Es mejor utilizar el tiempo y el esfuerzo para escribir el elenco que refactorizar el programa para eliminar cualquiera de los dos primeros puntos.

Si puede refactorizar un programa a bajo costo para que el compilador deduzca el tipo de tiempo de ejecución, o para refactorizar el programa de modo que no necesite la capacidad del tipo más derivado, hágalo. Se agregaron downcasts al lenguaje para aquellas circunstancias en las que es difícil y costoso refactorizar el programa.

¿Por qué el lenguaje admite el downcasting?

C # fue inventado por programadores pragmáticos que tienen trabajos que hacer, para programadores pragmáticos que tienen trabajos que hacer. Los diseñadores de C # no son puristas de OO. Y el sistema de tipo C # no es perfecto; por diseño, subestima las restricciones que se pueden colocar en el tipo de tiempo de ejecución de una variable.

Además, el downcasting es muy seguro en C #. Tenemos una fuerte garantía de que el downcast se verificará en tiempo de ejecución y, si no se puede verificar, el programa hace lo correcto y falla. Esto es maravilloso; significa que si su comprensión 100% correcta de la semántica de tipos resulta ser 99.99% correcta, entonces su programa funciona el 99.99% del tiempo y se bloquea el resto del tiempo, en lugar de comportarse de manera impredecible y corromper los datos del usuario 0.01% del tiempo .

EJERCICIO: Hay al menos una forma de producir un downcast en C # sin usar un operador de conversión explícito. ¿Puedes pensar en tales escenarios? Dado que estos también son olores potenciales de código, ¿qué factores de diseño cree que entraron en el diseño de una característica que podría producir un bloqueo abatido sin tener un reparto manifiesto en el código?

Los controladores de eventos generalmente tienen la firma MethodName(object sender, EventArgs e). En algunos casos, es posible manejar el evento sin tener en cuenta qué tipo senderes, o incluso sin usarlo sender, pero en otros se senderdebe convertir a un tipo más específico para manejar el evento.

Por ejemplo, puede tener dos TextBoxsy desea utilizar un solo delegado para controlar un evento de cada uno de ellos. Entonces necesitaría convertir sendera a TextBoxpara poder acceder a las propiedades necesarias para manejar el evento:

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

Sí, en este ejemplo, podría crear su propia subclase de la TextBoxcual hizo esto internamente. Sin embargo, no siempre es práctico o posible.

Necesitas un downcasting cuando algo te da un supertipo y necesitas manejarlo de manera diferente dependiendo del subtipo.

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, esto no huele bien. En un mundo perfecto Donationtendría un método abstracto getValuey la implementación de cada subtipo tendría una implementación adecuada.

Pero, ¿qué pasa si estas clases son de una biblioteca que no puede o no quiere cambiar? Entonces no hay otra opción.

Para agregar a la respuesta de Eric Lippert ya que no puedo comentar ...

A menudo puede evitar el downcasting refactorizando una API para usar genéricos. Pero los genéricos no se agregaron al lenguaje hasta la versión 2.0 . Por lo tanto, incluso si su propio código no necesita admitir versiones en idiomas antiguos, puede encontrarse utilizando clases heredadas que no están parametrizadas. Por ejemplo, alguna clase puede definirse para llevar una carga útil de tipo Object, que se ve obligado a lanzar al tipo que realmente sabe que es.

Existe una compensación entre los idiomas estáticos y dinámicamente escritos. La escritura estática le da al compilador mucha información para poder hacer garantías bastante sólidas sobre la seguridad de (partes de) programas. Sin embargo, esto tiene un costo, porque no solo necesita saber que su programa es correcto, sino que debe escribir el código apropiado para convencer al compilador de que este es el caso. En otras palabras, hacer reclamos es más fácil que probarlos.

Hay construcciones "inseguras" que le ayudan a hacer afirmaciones no comprobadas al compilador. Por ejemplo, llamadas incondicionales Nullable.Value, rechazos incondicionales, dynamicobjetos, etc. Le permiten hacer valer un reclamo ("Afirmo que el objeto aes un String, si me equivoco, arrojar un InvalidCastException") sin necesidad de probarlo. Esto puede ser útil en casos en los que demostrar que es significativamente más difícil de lo que vale la pena.

Abusar de esto es arriesgado, razón por la cual existe la notación explícita de downcast y es obligatoria; Es una sal sintáctica destinada a llamar la atención sobre una operación insegura. El lenguaje podría haberse implementado con un downcast implícito (donde el tipo inferido no es ambiguo), pero eso ocultaría esta operación insegura, lo que no es deseable.

Downcasting se considera malo por un par de razones. Principalmente pienso porque es anti-OOP.

OOP realmente me gustaría si nunca tuvieras que abatirlo ya que su "razón de ser" es que el polimorfismo significa que no tienes que ir

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

solo lo haces

x.DoThing()

y el código automáticamente hace lo correcto.

Hay algunas razones "difíciles" para no rechazar:

• En C ++ es lento.
• Obtiene un error de tiempo de ejecución si elige el tipo incorrecto.

Pero la alternativa al downcasting en algunos escenarios puede ser bastante fea.

El ejemplo clásico es el procesamiento de mensajes, donde no desea agregar la función de procesamiento al objeto, sino mantenerla en el procesador de mensajes. Luego tengo una tonelada MessageBaseClassen una matriz para procesar, pero también necesito cada una por subtipo para el procesamiento correcto.

Puede usar Double Dispatch para solucionar el problema ( https://en.wikipedia.org/wiki/Double_dispatch ) ... Pero eso también tiene sus problemas. O simplemente puede rechazar un código simple a riesgo de esas razones difíciles.

Pero esto fue antes de que se inventaran los genéricos. Ahora puede evitar el downcasting al proporcionar un tipo donde los detalles se especifiquen más adelante.

MessageProccesor<T> puede variar sus parámetros de método y valores de retorno según el tipo especificado, pero aún así proporcionar funcionalidad genérica

Por supuesto, nadie te está obligando a escribir código OOP y hay muchas características de lenguaje que se proporcionan pero que están mal vistas, como la reflexión.

Además de todo lo anterior, imagine una propiedad Tag que sea de tipo objeto. Proporciona una manera de almacenar un objeto de su elección en otro objeto para su uso posterior según lo necesite. Necesita abatir esta propiedad.

En general, no usar algo hasta hoy no siempre es una indicación de algo inútil ;-)

El uso más común de downcasting en mi trabajo se debe a que un idiota rompe el principio de sustitución de Liskov.

Imagine que hay una interfaz en alguna biblioteca de terceros.

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

Y 2 clases que lo implementan. Bary Qux. BarSe porta bien.

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

Pero Quxno se porta bien.

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

Bueno ... ahora no tengo otra opción. Me tengo que escribir cheque y (posiblemente) abatido con el fin de evitar tener mi programa vienen a un alto que se estrella.

Otro ejemplo del mundo real es el de WPF VisualTreeHelper. Utiliza abatido a emitir DependencyObjecta Visualy Visual3D. Por ejemplo, VisualTreeHelper.GetParent . El downcast ocurre en 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;
}