Qual è un uso corretto del downcasting?

Downcasting significa trasmettere da una classe base (o interfaccia) a una sottoclasse o foglia.

Un esempio di downcast potrebbe essere se si esegue il cast da System.Objectun altro tipo.

Il downcasting è impopolare, forse un odore di codice: la dottrina orientata agli oggetti è quella di preferire, ad esempio, la definizione e la chiamata di metodi virtuali o astratti anziché il downcasting.

• Quali sono, se del caso, i casi di utilizzo validi e corretti per il downcasting? Cioè, in quali circostanze è appropriato scrivere codice che esegue il downcast?
• Se la tua risposta è "nessuna", allora perché il downcasting è supportato dalla lingua?

Ecco alcuni usi corretti del downcasting.

E sono rispettosamente con veemenza in disaccordo con gli altri qui che affermano che l'uso dei downcast è sicuramente un odore di codice, perché credo che non ci sia un altro modo ragionevole per risolvere i problemi corrispondenti.

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

Se hai intenzione di dire che questi sono odori di codice, devi fornire loro soluzioni migliori (anche se vengono evitate a causa di inconvenienti). Non credo che esistano soluzioni migliori.

Il downcasting è impopolare, forse un odore di codice

Non sono d'accordo. Il downcasting è estremamente popolare ; un numero enorme di programmi del mondo reale contiene uno o più downcast. E non è forse un odore di codice. È sicuramente un odore di codice. Ecco perché è necessario che l'operazione di downcast sia manifestata nel testo del programma . È così che puoi notare più facilmente l'odore e dedicare attenzione alla revisione del codice su di esso.

in quali circostanze è appropriato scrivere un codice che esegue il downcast?

In ogni circostanza in cui:

• hai una conoscenza corretta al 100% di un fatto sul tipo di runtime di un'espressione che è più specifico del tipo di tempo di compilazione dell'espressione e
• è necessario sfruttare questo fatto per utilizzare una capacità dell'oggetto non disponibile nel tipo di tempo di compilazione e
• è un uso migliore del tempo e dello sforzo per scrivere il cast piuttosto che riformattare il programma per eliminare uno dei primi due punti.

Se è possibile effettuare il refactoring a buon mercato di un programma in modo che il compilatore possa dedurre il tipo di runtime o rifattorizzare il programma in modo tale che non sia necessaria la capacità del tipo più derivato, farlo. I downcasts sono stati aggiunti alla lingua per quelle circostanze in cui è difficile e costoso riformattare così il programma.

perché il downcasting è supportato dalla lingua?

C # è stato inventato da programmatori pragmatici che hanno lavori da svolgere, per programmatori pragmatici che hanno lavori da svolgere. I designer C # non sono puristi di OO. E il sistema di tipo C # non è perfetto; in base alla progettazione, sottostima le restrizioni che possono essere poste sul tipo di runtime di una variabile.

Inoltre, il downcasting è molto sicuro in C #. Abbiamo una forte garanzia che il downcast verrà verificato in fase di esecuzione e se non può essere verificato, il programma fa la cosa giusta e si blocca. Questo è meraviglioso; significa che se la tua corretta comprensione al 100% della semantica di tipo risulta corretta al 99,99%, il tuo programma funziona il 99,99% del tempo e si arresta in modo anomalo per il resto del tempo, invece di comportarsi in modo imprevedibile e corrompere i dati dell'utente 0,01% del tempo .

ESERCIZIO: esiste almeno un modo per produrre un downcast in C # senza usare un operatore cast esplicito. Riesci a pensare a tali scenari? Dal momento che questi sono anche potenziali odori di codice, quali sono i fattori di progettazione che ritieni siano andati nella progettazione di una funzionalità che potrebbe causare un arresto anomalo del downcast senza un cast manifest nel codice?

I gestori di eventi di solito hanno la firma MethodName(object sender, EventArgs e). In alcuni casi è possibile gestire l'evento senza tener conto di quale tipo sendersia, o addirittura senza utilizzarlo senderaffatto, ma in altri senderdeve essere eseguito il cast su un tipo più specifico per gestire l'evento.

Ad esempio, potresti avere due TextBoxse desideri utilizzare un singolo delegato per gestire un evento da ciascuno di essi. Quindi dovrai eseguire il cast senderin TextBoxmodo da poter accedere alle proprietà necessarie per gestire l'evento:

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

Sì, in questo esempio, è possibile creare la propria sottoclasse di TextBoxcui è stata eseguita internamente. Non sempre pratico o possibile, però.

Devi effettuare il downcasting quando qualcosa ti dà un supertipo e devi gestirlo in modo diverso a seconda del sottotipo.

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, questo non ha un buon odore. In un mondo perfetto Donationavrebbe un metodo astratto getValuee ogni sottotipo di implementazione avrebbe un'implementazione appropriata.

Ma cosa succede se queste classi provengono da una libreria che non puoi o non vuoi cambiare? Quindi non c'è altra opzione.

Da aggiungere alla risposta di Eric Lippert poiché non posso commentare ...

Spesso è possibile evitare il downcasting rifattorizzando un'API per utilizzare generici. Ma i generici non sono stati aggiunti alla lingua fino alla versione 2.0 . Quindi, anche se il tuo codice non ha bisogno di supportare versioni in lingua antica, potresti trovarti a utilizzare classi legacy che non sono parametrizzate. Ad esempio, alcune classi possono essere definite per trasportare un payload di tipo Object, che sei costretto a trasmettere al tipo che conosci effettivamente.

Esiste un compromesso tra le lingue statiche e quelle tipizzate dinamicamente. La digitazione statica fornisce al compilatore molte informazioni per essere in grado di fornire garanzie piuttosto forti sulla sicurezza di (parti di) programmi. Questo ha un costo, tuttavia, perché non solo devi sapere che il tuo programma è corretto, ma devi scrivere il codice appropriato per convincere il compilatore che è così. In altre parole, fare affermazioni è più facile che provarle.

Esistono costrutti "non sicuri" che ti aiutano a fare affermazioni non comprovate al compilatore. Ad esempio, chiamate incondizionate a Nullable.Value, downcasts incondizionati, dynamicoggetti, ecc. Ti permettono di affermare un reclamo ("Asserisco che l'oggetto aè un String, se sbaglio, lancia un InvalidCastException") senza bisogno di dimostrarlo. Questo può essere utile nei casi in cui dimostrarlo è significativamente più difficile che utile.

Abusare di questo è rischioso, motivo per cui esiste la notazione esplicita del downcast ed è obbligatoria; è sale sintattico destinato ad attirare l'attenzione su un'operazione non sicura. Il linguaggio avrebbe potuto essere implementato con downcasting implicito (dove il tipo inferito non è ambiguo), ma ciò nasconderebbe questa operazione non sicura, che non è desiderabile.

Il downcasting è considerato negativo per un paio di motivi. Principalmente penso perché è anti-OOP.

OOP lo gradirebbe davvero se non avessi mai dovuto eseguire il downcast poiché la sua "ragion d'essere" è che il polimorfismo significa che non devi andare

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

lo fai e basta

x.DoThing()

e il codice fa magicamente automaticamente la cosa giusta.

Esistono alcuni motivi "difficili" per non effettuare il downcast:

• In C ++ è lento.
• Si ottiene un errore di runtime se si sceglie il tipo sbagliato.

Ma l'alternativa al downcasting in alcuni scenari può essere piuttosto brutta.

L'esempio classico è l'elaborazione dei messaggi, in cui non si desidera aggiungere la funzione di elaborazione all'oggetto, ma conservarla nel processore dei messaggi. Ho quindi una tonnellata di MessageBaseClassin un array da elaborare, ma ho anche bisogno di ognuno per sottotipo per l'elaborazione corretta.

Puoi usare Double Dispatch per aggirare il problema ( https://en.wikipedia.org/wiki/Double_dispatch ) ... Ma anche questo ha i suoi problemi. Oppure puoi semplicemente eseguire il downcast per alcuni semplici codici a rischio di quei motivi difficili.

Ma questo è stato prima dell'invenzione di Generics. Ora puoi evitare il downcasting fornendo un tipo in cui i dettagli specificati in seguito.

MessageProccesor<T> può variare i parametri del metodo e restituire i valori in base al tipo specificato, ma fornisce comunque funzionalità generiche

Ovviamente nessuno ti obbliga a scrivere codice OOP e ci sono molte funzionalità linguistiche che vengono fornite ma disapprovate, come la riflessione.

Oltre a tutto ciò che è stato detto prima, immagina una proprietà Tag di tipo object. Ti fornisce un modo per archiviare un oggetto a tua scelta in un altro oggetto per un uso successivo di cui hai bisogno. È necessario downcast questa proprietà.

In generale, non usare qualcosa fino ad oggi non è sempre un'indicazione di qualcosa di inutile ;-)

L'uso più comune del downcasting nel mio lavoro è dovuto a qualche idiota che infrange il principio di sostituzione di Liskov.

Immagina che ci sia un'interfaccia in alcune librerie di terze parti.

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

E 2 classi che lo implementano. Bare Qux. Barè ben educato.

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

Ma Quxnon è ben educato.

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

Bene ... ora non ho scelta. Io devo digitare controllo e (possibilmente) abbattuto al fine di evitare di avere il mio programma venire a una battuta d'arresto crash.

Un altro esempio del mondo reale è quello di WPF VisualTreeHelper. Usa downcast per trasmettere DependencyObjecta Visuale Visual3D. Ad esempio, VisualTreeHelper.GetParent . Il downcast si verifica 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;
}