Методы расширения для IDictionary и IReadOnlyDictionary

Вам нужен только один метод расширения. Переопределите его следующим образом:

public static TValue? GetNullableKey<TKey, TValue>(this IEnumerable<KeyValuePair<TKey, TValue>> dictionary, TKey, key) where TValue : struct
{
    // Your code here.
    // Per @nmclean: to reap performance benefits of dictionary lookup, try to cast
    //               dictionary to the expected dictionary type, e.g. IDictionary<K, V> or
    //               IReadOnlyDictionary<K, V>. Thanks for that nmclean!
}

И IDictionary<TKey, TValue>, и IReadOnlyDictionary<TKey, TValue> наследуются от IEnumerable<KeyValuePair<TKey, TValue>>.

ХТН.

ОБНОВЛЕНИЕ: чтобы ответить на ваш вопрос в комментариях

Если вам не нужно вызывать методы, которые появляются только в одном или другом интерфейсе (т. е. вы вызываете только методы, которые существуют в IEnumerable<KeyValuePair<TKey, TValue>>), то нет, вам не нужен этот код.

Если вам нужно вызывать методы в интерфейсе IDictionary<TKey, TValue> или IReadOnlyDictionary<TKey, TValue>, которых нет в общем базовом интерфейсе, тогда да, вам нужно будет увидеть, является ли ваш объект одним или другим, чтобы узнать, какие методы допустимы. называется.

ОБНОВЛЕНИЕ: возможно (скорее всего) вам не следует использовать это решение

Итак, технически это решение является правильным при ответе на вопрос ОП, как указано. Однако это действительно не очень хорошая идея, как прокомментировали другие ниже, и как я признал эти комментарии правильными.

Во-первых, весь смысл словаря/карты заключается в поиске O (1) (постоянное время). Используя приведенное выше решение, вы превратили операцию O(1) в операцию O(n) (линейное время). Если в вашем словаре 1 000 000 элементов, поиск значения ключа занимает в 1 миллион раз больше времени (если вам действительно не повезло). Это может существенно повлиять на производительность.

А маленький словарь? Что ж, тогда возникает вопрос, действительно ли вам нужен словарь? Не лучше ли со списком? Или, возможно, еще лучший вопрос: когда вы начинаете замечать влияние на производительность использования поиска O(n) вместо O(1) и как часто вы ожидаете выполнять такой поиск?

Наконец, ситуация OP с объектом, который реализует оба IReadOnlyDictionary<TKey, TValue> и IDictionary<TKey, TValue>, довольно странная, поскольку поведение IDictionary<TKey, TValue> является надмножеством поведения IReadOnlyDictionary<TKey, TValue>. И стандартный класс Dictionary<TKey, TValue> уже реализует оба этих интерфейса. Поэтому, если бы тип OP (я предполагаю, специализированный) вместо этого унаследовал от Dictionary<TKey, TValue>, то, когда требовалась функциональность только для чтения, тип можно было бы просто преобразовать в IReadOnlyDictionary<TKey, TValue>, возможно, вообще избегая всей этой проблемы. Даже если проблема не была неизбежной (например, где-то делается приведение к одному из интерфейсов), все равно было бы лучше реализовать два метода расширения, по одному для каждого из интерфейсов.

Я думаю, что прежде чем я закончу эту тему, необходимо сделать еще один пункт. Преобразование Dictionary<TKey, TValue> в IReadOnlyDictionary<TKey, TValue> гарантирует только то, что все, что получает преобразованное значение, само не сможет изменить базовую коллекцию. Однако это не означает, что другие ссылки на экземпляр словаря, из которого была создана приведенная ссылка, не изменят базовую коллекцию. Это одна из проблем, связанных с интерфейсами коллекций IReadOnly*. Коллекции, на которые ссылаются эти интерфейсы, не могут быть действительно коллекциями «только для чтения» (или, как часто подразумевается, неизменяемыми), они просто предотвращают изменение коллекции конкретной ссылкой (несмотря на фактический экземпляр конкретного класса ReadOnly*). Это одна из причин (среди прочих), что было создано пространство имен System.Collections.Immutable классов коллекций. Коллекции в этом пространстве имен представляют собой действительно неизменяемые коллекции. «Мутации» этих коллекций приводят к тому, что возвращается совершенно новая коллекция, состоящая из измененного состояния, оставляя исходную коллекцию неизменной.

После некоторых экспериментов я вспомнил/обнаружил, что C# готов разрешать неоднозначности, предпочитая подклассы базовым классам. Таким образом, чтобы сделать это с безопасностью типов, вам нужны 3 метода расширения, а не один. И если у вас есть другие классы, которые, как Dictionary<TKey, TValue>, реализуют и IDictionary<TKey, TValue>, и IReadOnlyDictionary<TKey, TValue>, вам нужно писать все больше и больше методов расширения…

Следующее делает компилятор совершенно счастливым. Не требуется приведения, чтобы использовать переданный словарь в качестве словаря. Моя стратегия состоит в том, чтобы реализовать мой фактический код для наименьшего общего знаменателя, IReadOnlyDictionary<TKey, TValue>, использовать фасад для адаптации IDictionary<TKey, TValue> к этому (потому что вам может быть передан объект, который не реализует IReadOnlyDictionary<TKey, TValue>), и, чтобы избежать ошибки неоднозначности разрешения перегрузки метода , явно расширить Dictionary<TKey, TValue> напрямую.

using System;
using System.Collections;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.IO;
using System.Linq;

// Proof that this makes the compiler happy.
class Program
{
    static void Main(string[] args)
    {
        // This is written to try to demonstrate an alternative,
        // type-clean way of handling http://stackoverflow.com/q/18641693/429091
        var x = "blah".ToDictionary(
            c => c,
            c => (int)c);
        // This would be where the ambiguity error would be thrown,
        // but since we explicitly extend Dictionary<TKey, TValue> dirctly,
        // we can write this with no issue!
        x.WriteTable(Console.Out, "a");
        IDictionary<char, int> y = x;
        y.WriteTable(Console.Out, "b");
        IReadOnlyDictionary<char, int> z = x;
        z.WriteTable(Console.Out, "lah");
    }
}

// But getting compile-time type safety requires so much code duplication!
static class DictionaryExtensions
{
    // Actual implementation against lowest common denominator
    public static void WriteTable<TKey, TValue>(this IReadOnlyDictionary<TKey, TValue> dict, TextWriter writer, IEnumerable<TKey> keys)
    {
        writer.WriteLine("-");
        foreach (var key in keys)
            // Access values by key lookup to prove that we’re interested
            // in the concept of an actual dictionary/map/lookup rather
            // than being content with iterating over everything.
            writer.WriteLine($"{key}:{dict[key]}");
    }

    // Use façade/adapter if provided IDictionary<TKey, TValue>
    public static void WriteTable<TKey, TValue>(this IDictionary<TKey, TValue> dict, TextWriter writer, IEnumerable<TKey> keys)
        => new ReadOnlyDictionary<TKey, TValue>(dict).StaticCast<IReadOnlyDictionary<TKey, TValue>>().WriteTable(writer, keys);

    // Use an interface cast (a static known-safe cast).
    public static void WriteTable<TKey, TValue>(this Dictionary<TKey, TValue> dict, TextWriter writer, IEnumerable<TKey> keys)
        => dict.StaticCast<IReadOnlyDictionary<TKey, TValue>>().WriteTable(writer, keys);

    // Require known compiletime-enforced static cast http://stackoverflow.com/q/3894378/429091
    public static T StaticCast<T>(this T o) => o;
}

Самое неприятное в этом подходе то, что вам нужно написать так много шаблонов — два метода расширения тонкой оболочки и одну реальную реализацию. Однако я думаю, что это может быть оправдано, потому что код, использующий расширения, может быть простым и понятным. Уродство содержится в классе расширений. Кроме того, поскольку реализация расширения содержится в одном методе, вам не нужно беспокоиться об обновлении перегрузок при обновлении варианта IReadOnlyDictionary<TKey, TValue>. Компилятор даже напомнит вам обновить перегрузки, если вы измените типы параметров, если вы не добавляете новые параметры со значениями по умолчанию.

Чтобы получить желаемое поведение в вашем случае, см. fourpastmidnight answer.

Однако, чтобы ответить на ваш вопрос напрямую, нет, невозможно заставить работать синтаксис myDic.GetNullable, когда есть два метода расширения. Сообщение об ошибке, которое вы получили, было правильным, говоря, что оно неоднозначно, потому что у него нет возможности узнать, какой из них вызывать. Если ваш метод IReadOnlyDictionary сделал что-то другое, должен он делать это или нет для Dictionary<TKey, TValue>?

Именно по этой причине существует метод AsEnumerable. Методы расширения определены как для IEnumerable, так и для IQueryable с одинаковыми именами, поэтому иногда вам нужно привести объекты, реализующие оба, чтобы гарантировать, что будет вызван конкретный метод расширения.

Предположим, что у ваших двух методов действительно разные реализации, вы можете включить похожие методы, например:

public static IReadOnlyDictionary<TKey, TValue> AsReadOnly<TKey, TValue>(this IDictionary<TKey, TValue> dictionary) {
    return (IReadOnlyDictionary<TKey, TValue>)dictionary;
}

public static IDictionary<TKey, TValue> AsReadWrite<TKey, TValue>(this IReadOnlyDictionary<TKey, TValue> dictionary) {
    return (IDictionary<TKey, TValue>)dictionary;
}

Затем вызовите методы следующим образом:

dictionary.AsReadOnly().GetNullable(key);
dictionary.AsReadWrite().GetNullable(key);

(Технически метод с именем AsReadOnly должен возвращать настоящий ReadOnlyDictionary, но это просто для демонстрации)