Utiliser l'héritage pour créer une collection personnalisée, sécurisée et sécurisée?

Question

Je ne suis pas clair avec la déclaration ci-dessus. Ce serait génial si quelqu'un peut expliquer comment nous pouvons utiliser l'héritage pour créer une collection personnalisée, sécurisée et sécurisée.

Merci

Answer 1

Eh bien, vous pourriez obtenir un nouveau type de Collection<T> et passer outre SetItem et InsertItem: jeter une exception si la nouvelle valeur est nulle. Est-ce le genre de choses auxquelles vous pensiez?

Ce serait:

• personnalisés: bien, vous Redéfinition des méthodes de personnaliser le comportement normal
• typées: en vertu de dérivation de Collection<T>; la classe de base empêche les valeurs d'un type inapproprié étant ajouté
• Null-sécurité: vos surcharges empêcheraient les valeurs nulles d'être jamais présent dans la collection

Vous pouvez même garder générique:

// Note: you could include "where T : class"; on the other hand 
// you might have some reason to want a NullSafeCollection<int?> 
// which you knew had no null values in. 
public class NullSafeCollection<T> : Collection<T> 
{ 
    protected override InsertItem(int index, T item) 
    { 
     if (item == null) 
     { 
      throw new ArgumentNullException("item"); 
     } 
     base.InsertItem(index, item); 
    } 

    // Likewise for SetItem 
} 

Answer 2

Je pense que le problème réside dans le terme ambigu "null safe".

En général, pour une collection de typesafe, vous utiliseriez des génériques, pas d'héritage.

Donc je suppose que ce qui est désiré est une collection dérivée qui ajoute des "vérifications de sécurité nulles" (quoi que cela signifie dans votre cas) au-dessus d'une collection générique standard. Excepté en C#, les collections génériques n'utilisent pas de fonctions virtuelles, elles ne peuvent donc pas être étendues (quiconque ayant choisi de le faire sans que les classes soient scellées ne puisse plus jamais être programmé). Vous devrez donc utiliser les anciennes collections non génériques .NET 1.x comme Collection, et les remplacer par "vérifications de sécurité de type" et "vérifications de sécurité nulles".

D'autre part, si vous utilisez « null safe » au sens je, puis les collections les plus courantes telles que List<T>, LinkedList<T>, Stack<T>, Queue<T> sont déjà « nul sûr » en ce sens qu'ils ne se brisent pas ou générer une exception si vous transmettez null. D'autre part, Dictionary<TKey,TValue> n'est pas à sécurité nulle car il appelle GetHashCode sur l'argument. Vous devrez les retravailler pour définir le code de hachage null. HashSet<T> fait réellement cela, définissant 0 comme le hachage de null. De même pour SortedList<TKey,TValue> et SortedDictionary<TKey,TValue>, vous devez définir où se trouve null dans l'ordre de tri. Pour autant que je sache, il n'y a aucun moyen de faire en sorte que ces collections se comportent correctement. L'absence de support null dans ces classes n'est pas causée par l'échec de la fonction de hachage ou du comparateur lorsque null est passé, il est provoqué par des vérifications préventives dans toutes les API publiques. Ceux-ci ne peuvent pas être corrigés par héritage public, et C# (.NET en général) n'autorise pas l'héritage privé. Sur le bon côté, System.Collections.ObjectModel.KeyedCollection<TKey,TItem> fait tout son possible pour ne pas laisser les clés NULL être vu par le dictionnaire sous-jacent. Cependant, il étend Dictionary<TKey,TValue> pour ajouter une sécurité nulle à travers le confinement, pas l'héritage.