Qu'est-ce qu'une utilisation appropriée du downcasting?

Le downcasting signifie la conversion d'une classe de base (ou interface) vers une classe sous-classe ou feuille.

Un exemple de downcast pourrait être si vous lancez à partir System.Objectd'un autre type.

Le downcasting est impopulaire, peut-être une odeur de code: la doctrine orientée objet consiste à préférer, par exemple, la définition et l’appel de méthodes virtuelles ou abstraites au lieu d’un downcasting.

• Quels sont, le cas échéant, des cas d'utilisation corrects et appropriés pour le downcasting? C'est-à-dire, dans quelles circonstances est-il approprié d'écrire du code qui est downscast?
• Si votre réponse est "néant", alors pourquoi le downcasting est-il pris en charge par la langue?

Voici quelques utilisations appropriées du downcasting.

Et je respectueusement avec véhémence en désaccord avec d' autres ici qui disent l'utilisation de downcasts est certainement une odeur de code, parce que je crois qu'il n'y a pas d' autre moyen raisonnable de résoudre les problèmes correspondants.

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 vous dites que ce sont des odeurs de code, vous devez leur proposer de meilleures solutions (même si elles sont évitées en raison d'inconvénients). Je ne crois pas qu'il existe de meilleures solutions.

Le downcasting est impopulaire, peut-être une odeur de code

Je ne suis pas d'accord. Le downcasting est extrêmement populaire ; un très grand nombre de programmes du monde réel contiennent une ou plusieurs diffusions à la baisse. Et ce n'est peut- être pas une odeur de code. C'est vraiment une odeur de code. C'est pourquoi l'opération de downcasting doit être manifeste dans le texte du programme . C’est pour que vous puissiez plus facilement remarquer l’odeur et consacrer votre attention à la révision de code.

dans quelles circonstances est-il approprié d'écrire du code qui diffuse en aval?

Dans toutes les circonstances où:

• vous avez une connaissance correcte à 100% d'un fait concernant le type à l'exécution d'une expression qui est plus spécifique que le type à la compilation de l'expression, et
• vous devez en tirer parti pour utiliser une fonctionnalité de l'objet non disponible sur le type à la compilation, et
• le temps et les efforts consacrés à l'écriture du casting sont meilleurs que le refactorisation du programme pour éliminer l'un ou l'autre des deux premiers points.

Si vous pouvez refactoriser à moindre coût un programme afin que soit le compilateur puisse déduire le type d'exécution, soit le refactoriser afin que vous n'ayez pas besoin de la capacité du type le plus dérivé, faites-le. Des abaissements ont été ajoutés à la langue dans les cas où il est difficile et coûteux de restructurer le programme.

pourquoi le downcasting est-il pris en charge par la langue?

C # a été inventé par des programmeurs pragmatiques ayant des tâches à accomplir, pour des programmeurs pragmatiques ayant des tâches à accomplir. Les concepteurs C # ne sont pas des puristes OO. Et le système de type C # n’est pas parfait; de par sa conception, il sous-estime les restrictions pouvant être imposées au type d’exécution d’une variable.

De plus, le downcasting est très sûr en C #. Nous avons une forte garantie que le downcast sera vérifié au moment de l'exécution. S'il ne peut pas être vérifié, le programme fait le bon choix et se bloque. C'est merveilleux; cela signifie que si votre compréhension correcte à 100% de la sémantique des types s'avère correcte à 99,99%, votre programme fonctionne 99,99% du temps et se bloque le reste du temps, au lieu de se comporter de manière imprévisible et de corrompre les données utilisateur. .

EXERCICE: Il existe au moins un moyen de produire un downcast en C # sans utiliser d'opérateur de distribution explicite. Pouvez-vous penser à de tels scénarios? Etant donné que ce sont aussi des odeurs potentielles de code, quels facteurs ont été à l’origine de la conception d’une fonctionnalité susceptible de provoquer un plantage sans affichage du code dans le code?

Les gestionnaires d'événements ont généralement la signature MethodName(object sender, EventArgs e). Dans certains cas, il est possible de gérer l'événement sans tenir compte du type sender, voire de ne pas utiliser senderdu tout, mais dans d'autres cas, il senderdoit être converti en un type plus spécifique pour gérer l'événement.

Par exemple, vous pouvez avoir deux TextBoxs et utiliser un seul délégué pour gérer un événement de chacun d'eux. Ensuite, vous devez transtyper senderen un TextBoxafin de pouvoir accéder aux propriétés nécessaires pour gérer l'événement:

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

Oui, dans cet exemple, vous pouvez créer votre propre sous-classe, TextBoxqui l’a fait en interne. Pas toujours pratique ou possible, cependant.

Vous avez besoin d'un downcasting lorsque quelque chose vous donne un super-type et que vous devez le gérer différemment en fonction du sous-type.

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

Non, ça ne sent pas bon. Dans un monde parfait, il Donationy aurait une méthode abstraite getValueet chaque sous-type implémenté aurait une implémentation appropriée.

Mais que se passe-t-il si ces classes proviennent d'une bibliothèque que vous ne pouvez pas ou ne voulez pas changer? Alors il n'y a pas d'autre option.

Pour ajouter à la réponse d'Eric Lippert puisque je ne peux pas commenter ...

Vous pouvez souvent éviter le downcasting en restructurant une API pour qu'elle utilise des génériques. Mais les génériques n’ont pas été ajoutés à la langue jusqu’à la version 2.0 . Ainsi, même si votre propre code n'a pas besoin de prendre en charge les versions de langue ancienne, vous pouvez vous retrouver à utiliser des classes héritées qui ne sont pas paramétrées. Par exemple, certaines classes peuvent être définies pour porter une charge utile de type Object, que vous êtes obligé de transtyper vers le type que vous connaissez réellement.

Il existe un compromis entre les langages statiques et à typage dynamique. Le typage statique fournit au compilateur de nombreuses informations lui permettant de donner des garanties assez fortes quant à la sécurité des (parties de) programmes. Cela a toutefois un coût, car non seulement vous devez savoir que votre programme est correct, mais vous devez écrire le code approprié pour convaincre le compilateur que tel est le cas. En d’autres termes, il est plus facile de faire des réclamations que de les prouver.

Il existe des constructions "non sûres" qui vous aident à faire des assertions non prouvées au compilateur. Par exemple, appels inconditionnels à Nullable.Value, downcasts, dynamicobjets, etc. , sans condition . Ils vous permettent d'affirmer une revendication ("J'affirme que l'objet aest un String, si je me trompe, jette un InvalidCastException") sans qu'il soit nécessaire de le prouver. Cela peut être utile dans les cas où il est beaucoup plus difficile de prouver que cela vaut la peine.

Abuser de cela est risqué, c'est précisément pourquoi la notation explicite à la baisse existe et est obligatoire; c'est un sel syntaxique destiné à attirer l'attention sur une opération non sécurisée. Le langage aurait pu être implémenté avec un downcasting implicite (où le type inféré est sans ambiguïté), mais cela masquerait cette opération non sécurisée, ce qui n'est pas souhaitable.

La décadence est considérée comme mauvaise pour plusieurs raisons. Principalement, je pense parce que c'est anti-POO.

OOP aimerait vraiment si vous n’avez jamais à baisser les bras, car sa raison d’être est que le polymorphisme signifie que vous n’êtes pas obligé de partir.

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

tu fais juste

x.DoThing()

et le code fait comme par magie la bonne chose.

Il y a des raisons «difficiles» à ne pas abaisser:

• En C ++, c'est lent.
• Vous obtenez une erreur d'exécution si vous choisissez un type incorrect.

Mais l’alternative au downcasting dans certains scénarios peut être assez laide.

L'exemple classique est le traitement des messages, dans lequel vous ne souhaitez pas ajouter la fonction de traitement à l'objet, mais la conserver dans le processeur de messages. J'ai alors une tonne de données MessageBaseClassdans un tableau à traiter, mais j'ai également besoin de chaque sous-type pour un traitement correct.

Vous pouvez utiliser Double Dispatch pour résoudre le problème ( https://en.wikipedia.org/wiki/Double_dispatch ) ... Mais cela a aussi ses problèmes. Vous pouvez également vous contenter d'un code simple au risque de ces raisons difficiles.

Mais c'était avant l'invention des génériques. Maintenant, vous pouvez éviter le downcasting en fournissant un type où les détails spécifiés ultérieurement.

MessageProccesor<T> peut modifier les paramètres de sa méthode et retourner des valeurs en fonction du type spécifié, tout en fournissant une fonctionnalité générique

Bien sûr, personne ne vous oblige à écrire du code POO et de nombreuses fonctionnalités linguistiques sont fournies, mais mal vues, telles que la réflexion.

En plus de tout ce qui a été dit précédemment, imaginez une propriété Tag de type objet. Il vous permet de stocker un objet de votre choix dans un autre objet pour une utilisation ultérieure, selon vos besoins. Vous avez besoin d'abaisser cette propriété.

En général, ne pas utiliser quelque chose jusqu'à ce jour n'est pas toujours une indication d'inutile ;-)

L'utilisation la plus commune de la décroissance dans mon travail est due à un idiot qui a brisé le principe de substitution de Liskov.

Imaginez qu'il y ait une interface dans une bibliothèque tierce.

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

Et 2 classes qui l'implémentent. Baret Qux. Barest bien comporté.

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

Mais Quxne se comporte pas bien.

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

Eh bien ... maintenant je n'ai pas le choix. Je dois taper check et (éventuellement) downcast afin d'éviter que mon programme ne s'arrête brusquement.

WPF est un autre exemple concret VisualTreeHelper. Il utilise downcast pour lancer DependencyObjectvers Visualet Visual3D. Par exemple, VisualTreeHelper.GetParent . Le downcast se produit dans 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;
}