La méthode cache-t-elle toujours une bonne idée

Question

En C #, le modificateur new peut être utilisé pour masquer une méthode de classe de base sans remplacer la méthode de classe de base.

Je n'ai jamais rencontré de situation où cacher une méthode était le meilleur choix disponible. Y a-t-il des situations où la dissimulation de méthode est le meilleur choix?

Answer 1

Il existe des raisons rares, mais très bonnes, d'utiliser la méthode de masquage. Eric Lippert a publié un excellent exemple sur son blog:

 interface IEnumerable<T> : IEnumerable { 
  new IEnumerator<T> GetEnumerator(); 
}
 

Cependant, je pense que la dissimulation devrait être l'exception et ne doit être utilisée qu'avec parcimonie.

Answer 2

J'ai tendance à l'utiliser parfois pour la commodité des appelants, quelque chose comme:

 abstract public class Animal { }

public class Mouse : Animal { }



public class AnimalTrap
{
    public Animal TrappedAnimal { get; }
}

public class MouseTrap : AnimalTrap
{
    new public Mouse TrappedAnimal
    {
        get { return (Mouse)base.TrappedAnimal; }
    }
}
 

Ainsi, l'appelant n'a pas à lancer lui-même Mouse lorsque la classe dérivée garantit que l'animal piégé sera toujours une souris. Et la fonctionnalité polymorphe reste intacte.

Answer 3

C'est souvent un bon choix lorsque vous êtes à la création de contrôles personnalisés, et que vous souhaitez empêcher certaines propriétés qui apparaissent dans le concepteur. Parfois, les propriétés ne sont pas substituables, mais le concepteur n'a pas de soins à ce sujet, il ne se soucie de savoir si ou non le niveau le plus bas de la propriété publique a l' [Browsable] d'attribut.

Par exemple, disons que votre commande ne prend pas en charge le rembourrage. Le Contrôle.Rembourrage de la propriété n'est pas remplaçable. Mais vous savez aussi que rien de mauvais va se passer si quelqu'un définit la marge, il est juste que la propriété ne pas faire n'importe quoi, donc vous ne voulez pas que vos utilisateurs à voir dans le concepteur et pense qu'elle fonctionne réellement. Donc, le cacher:

public class MyControl : Control
{
    [Browsable(false)]
    public new Padding Padding
    {
        get { return base.Padding; }
        set { base.Padding = value; }
    }
}

Dans ce cas, nous sommes littéralement à l'aide de membres de la clandestinité pour masquer le membre - de la designer.

En aparté, je suis conscient qu'il existe d'autres moyens d'atteindre cet objectif - c'est juste une option possible.

Answer 4

L'exemple le plus courant auquel je peux penser ici est des choses comme DbCommand vs SqlCommand ; les types concrets ( SqlCommand etc.) font généralement beaucoup de masquage de méthodes pour que les types de retour de propriétés / méthodes affichent le type d'implémentation correct. Cela est dû au fait que les objets associés eux-mêmes ont des fonctionnalités supplémentaires (spécifiques à l'implémentation), et l'appelant ne veut pas avoir à transtyper à chaque appel.

Answer 5

Oui, si vous êtes, par exemple, juste un consommateur d'une classe de base et qu'une nouvelle version de la classe de base est publiée qui a tout d'un coup la méthode avec la même signature exacte que l'une des méthodes que vous avez déjà implémentées dans votre dérivée , vous devez pouvoir masquer la méthode de classe de base et utiliser new pour indiquer clairement que vous masquez la méthode de classe de base ...