использовать наследование для создания настраиваемой, безопасной для типов, нулевой безопасной коллекции? - PullRequest
Новая
       13

использовать наследование для создания настраиваемой, безопасной для типов, нулевой безопасной коллекции?

2 голосов
/ 04 апреля 2010

Я не совсем согласен с приведенным выше утверждением. Было бы здорово, если бы кто-нибудь мог объяснить, как мы можем использовать наследование для создания настраиваемой, безопасной и нулевой безопасной коллекции?

Спасибо

Ответы [ 2 ]

3 голосов
/ 04 апреля 2010

Ну, вы можете получить новый тип из Collection<T> и переопределить SetItem и InsertItem: вывести исключение, если новое значение нулевой. Это то, о чем ты думал?

Это было бы:

  • Пользовательский: вы переопределяете методы для настройки нормального поведения
  • Тип-безопасный: в силу производного от Collection<T>; базовый класс предотвращает добавление значений неподходящего типа
  • Null-safe: ваши переопределения предотвратят появление в коллекции нулевых значений

Вы можете даже сделать его общим: 

// 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
}
2 голосов
/ 04 апреля 2010

Я думаю, что проблема заключается в двусмысленном термине «нулевой сейф».

Как правило, для типизированной коллекции вы должны использовать дженерики, а не наследование.

Итак, я предполагаю, что требуется производная коллекция, которая добавляет «нулевые проверки безопасности» (что бы это ни значило в вашем случае) поверх некоторой стандартной универсальной коллекции. За исключением C #, универсальные коллекции не используют виртуальные функции, поэтому они не могут быть расширены (кто бы ни решил сделать это, не закрывая при этом классы, он должен быть навсегда лишен возможности программирования).

Таким образом, вам придется использовать старые неуниверсальные коллекции .NET 1.x, такие как Collection, и переопределить их «проверками безопасности типов» и «проверками безопасности null».

С другой стороны, если вы используете «нулевой сейф» в том смысле, в котором я это сделал бы, то более распространенные коллекции, такие как List<T>, LinkedList<T>, Stack<T>, Queue<T>, уже «нулевой сейф» в том, что они не аварийно завершают работу и не создают исключение, если вы передаете null. С другой стороны, Dictionary<TKey,TValue> небезопасен, так как вызывает аргумент GetHashCode. Вам придется переделать их, чтобы определить, что такое хэш-код null. HashSet<T> фактически делает это, определяя 0 как хэш null. Точно так же для SortedList<TKey,TValue> и SortedDictionary<TKey,TValue> вам необходимо определить, где null находится в порядке сортировки.

Насколько я могу судить, невозможно заставить эти коллекции работать правильно. Отсутствие поддержки null в этих классах вызвано не сбоем хеширующей функции или компаратора при передаче null, а обусловлено упреждающими проверками во всех общедоступных API. Они не могут быть исправлены публичным наследованием, и C # (.NET в целом) не разрешает частное наследование. С другой стороны, System.Collections.ObjectModel.KeyedCollection<TKey,TItem> делает все возможное, чтобы не дать нулевым ключам увидеть базовый словарь. Однако это расширяет Dictionary<TKey,TValue>, чтобы добавить нулевую безопасность через сдерживание, а не наследование.

...