Surpression ou évitement Avertissement CA2214

Question

Je suis dans une situation où je crée un objet appelé EntryEvent à partir des données que je reçois. Ces données doivent être analysées. L'événement de base est censé lancer l'analyse des données reçues par le constructeur et données à l'objet. Le sous-type sait comment analyser cet ensemble de données spécifique. Maintenant, lors de la compilation de ce code, j'obtiens l'avertissement CA2214, qui contient une chaîne d'appel à une méthode virtuelle. Bien qu'il puisse être mauvais d'avoir des conséquences imprévues, je ne sais pas comment obtenir le comportement requis: Analyser l'événement reçu sans avoir à appeler une méthode "Parse" supplémentaire de l'extérieur.

Le code en question est:

public abstract class BaseEvent 
{ 
    protected BaseEvent(object stuff) 
    { 
     this.ParseEvent(); 
    } 

    protected abstract void ParseEvent(); 
} 

public class EntryEvent : BaseEvent 
{ 
    public EntryEvent(object stuff) 
     : base(stuff) 
    { 
    } 

    protected override void ParseEvent() 
    { 
     // Parse event 
    } 
} 

Answer 1

Selon MSDN (l'accent est à moi):

Lorsqu'une méthode virtuelle est appelée, le type réel qui exécute la méthode n'est pas sélectionnée jusqu'à ce que temps d'exécution. Lorsqu'un constructeur appelle une méthode virtuelle, , il est possible que le constructeur de l'instance qui appelle la méthode n'ait pas été exécuté.

Donc, à mon avis, vous avez ces options (au moins):

1) Ne pas désactiver cet avertissement, mais supprimer ce message pour votre classe spécifique (s) documentant son comportement prévu (en supposant que vous prenez supplémentaire soin de faire face à un tel scénario). Ce n'est pas si grave si elle est limitée à quelques classes dans un environnement très contrôlé (après tout ... les avertissements ne sont pas des erreurs et ils peuvent être ignorés).

2) Supprimer cet appel de méthode virtuelle du constructeur de la classe de base mais laisser la déclaration de la méthode abstract à cet endroit. Les développeurs devront implémenter une telle méthode et pour l'appeler dans le constructeur, ils devront marquer leurs classes comme sealed. Enfin, ajoutez quelque part dans la documentation de classe/méthode que cette méthode doit être appelée dans leur constructeur et que leur classe doit être sealed pour le faire. Ils peuvent oublier appeler mais vous pouvez ajouter (pour les builds DEBUG) une vérification lorsque des propriétés ou méthodes sont accédées (par exemple en forçant, en tant que partie de l'interface de classe, à définir un indicateur spécifique). S'ils oublient de mettre le drapeau ou oublient d'appeler la méthode alors une exception sera levée ("Cet objet n'a pas été construit, ParseEvent() doit être appelé dans le constructeur des classes dérivées."). Je n'aime pas beaucoup cette méthode parce qu'elle ajoute de la complexité mais si votre hiérarchie de classe est trop grande (alors vous ne pouvez pas utiliser # 1) ou l'initialisation paresseuse (décrite dans # 3) n'est pas applicable alors il peut s'agir d'une solution fonctionnant. Je considérerais également pour changer la conception pour introduire une méthode d'usine qui appellera ParseEvent() pour chaque objet entièrement construit.

3) Changez un peu votre conception: reportez l'analyse au besoin. Par exemple:

public abstract class BaseEvent 
{ 
    public DateTime TimeStamp 
    { 
     get 
     { 
      if (_timestamp == null) 
       ParseEvent(); 

      return _timestamp.Value; 
     } 
     protected set { _timestamp = value; } 
    } 

    protected BaseEvent(object stuff) 
    { 
    } 

    protected abstract void ParseEvent(); 

    private DateTime? _timestamp; 
} 

Le dernier exemple est uniquement à des fins d'illustration, vous pouvez utiliser Lazy<T> faire même tâche dans une plus coincise, de manière claire et sûre fil. Bien sûr, en réalité, vous aurez plus de champs/propriétés et probablement l'analyse fournira toutes les valeurs en un coup (alors vous avez juste besoin d'un drapeau, pas besoin de Nullable/valeur spéciale sur chaque champ) C'est l'approche que je préfère, même si c'est plus bavard.