需要设计可同时使用“类”和“结构”类型约束的通用类

Question

For specific reasons I have to use 2 types of dictionary wrappers in my application (one for value types, one for instance types), the classes look as follows:

internal class StructDictionary<K, V> where V : struct
{
    public IDictionary<K, V> _dictionary = new Dictionary<K, V>();

    public StructDictionary(Dictionary<K, V> dictionary)
    {
        _dictionary = dictionary;
    }

    public V? this[K key]
    {
        get
        {
            V foundValue;
            return _dictionary.TryGetValue(key, out foundValue) ? foundValue : (V?)null;
        }
        set
        {
            if (!value.HasValue)
                return;

            _dictionary[key] = value.Value;
        }
    }
}

and for instance types

internal class InstanceDictionary<K, V> where V : class
{
    public IDictionary<K, V> _dictionary = new Dictionary<K, V>();

    public InstanceDictionary(Dictionary<K, V> dictionary)
    {
        _dictionary = dictionary;
    }

    public V this[K key]
    {
        get
        {
            V foundValue;
            return _dictionary.TryGetValue(key, out foundValue) ? foundValue : null;
        }
        set
        {
            if (value == null)
                return;

            _dictionary[key] = value;
        }
    }
}

These 2 classes are meant to be used as follows:

void Main()
{
    var structDictionary = new StructDictionary<string, double>(new Dictionary<string, double>(){{"key1",1}});
    var instanceDictionary = new InstanceDictionary<string, string>(new Dictionary<string, string>(){{"key1","value1"}});

    structDictionary["key1"] = 70;
    instanceDictionary["key1"] = "NEW_VAL";

}

Since the logic in the 2 dictionary wrappers is virtually the same I would like to replace the 2 classes with only one class without impacting performance since these objects are used extensively.

So far I have found this non-optimal solution where I basically return object from the indexer. This solution doesn't really work since there is some boxing/unboxing happening (see comments in the code below) and it's also using Convert.ChangeType which is not very fast.

internal class BetterDictionary<K, V>
{
    public IDictionary<K, V> _dictionary = new Dictionary<K, V>();

    public BetterDictionary(Dictionary<K, V> dictionary)
    {
        _dictionary = dictionary;
    }

    public object this[K key]
    {
        get
        {
            V foundValue;
            return _dictionary.TryGetValue(key, out foundValue) ? (object)foundValue /* Issue 1: boxing here when V is value type */: null;
        }
        set
        {
            if (value==null)
                return;

            _dictionary[key] = (V)Convert.ChangeType(value, typeof(V)); // Issue 2: slight performance hit due to ChangeType ?

            // more code here 
        }
    }
}

In conclusion, is there a better solution (a better BetterDictionary wrapper) that does not impact performance, basically I want a generic object that supports both value types and instance types for the V generic parameter.

EDIT In response to the question why do I need to use this somewhat peculiar dictionary wrapper, it's because I am working with a legacy UI library that has some particular quirks where I can only bind to objects with indexers in that form, additionaly I have to return null for non existent dictionary value. Basically I am transposing the dictionary data to be display as grid columns in a UI, I can't modify the UI and I can't modify the inner dictionaries, so I had to use a contrived wrapper like this.

Also the indexer set{} is actually running more code than just setting the dictionary value and that's why I can't use a dictionary.

Apologies for the lack of context, I will try to update the example with more context.

Answer 1

You should fix your design so that the indexer doesn't use null as a sentinel value.

For one, null is a perfectly valid reference type value. Maybe in your code, it's never used that way, but it's confusing to overload the value like that in any case. In any normal IDictionary<TKey, TValue> implementation, you'd be able to use null as the value for a given key.

For another, the code you posted seems wrong. The setters in both of your original classes and your new "combined" implementation all simply return if the passed value for the indexer is null . But if the key exists in the dictionary, this means that you can assign null to the given key, and then later if you retrieve the key's value, you'll get a non- null value back.

At the very least, each setter ought to look something more like this (using the value-type version as the example):

    set
    {
        if (!value.HasValue)
        {
            _dictionary.RemoveKey(key);
            return;
        }

        _dictionary[key] = value.Value;
    }

One comment suggests using (in a regular generic dictionary) default(V) as the "not found" return value, and then using a concrete Nullable<T> as the value-type type parameter V . This could work, but it has the same issues that using null as a sentinel for "not found" has when using reference types. Ie that's actually normally a perfectly valid dictionary value for any key. Using it instead to represent a "not found" value not makes the implementation confusing and inconsistent with any other dictionary implementation: null values aren't legal for a key; and to remove a key, you need to actually set its value to the non-legal null value (which only confuses matters more…it's not a legal value, but it's still something you have to assign to the indexer).

By design, your options for using null when dealing with value types are very limited. You can box (incurring the cost of that), or you can use Nullable<T> (which is incompatible with any reference type).

If you really must do this, I would recommend writing your own version of Nullable<T> that allows reference types:

struct NullableEx<T>
{
    private bool _hasValue;
    private T _value;

    public NullableEx(T value)
    {
        _hasValue = true;
        _value = value;
    }

    public bool HasValue { get { return _hasValue; } }
    public T Value { get { return _value; } }

    // You can also e.g. add implicit operators to convert
    // between T and NullableEx<T>, to implement equality
    // and hash code operations, etc.
}

Then you can make your indexer have the type NullableEx<V> in your class. It can return new NullableEx<V>() when the key isn't present.

The caller will need to check HasValue and Value explicitly, which IMHO is no more convenient than just using Dictionary<TKey, TValue>.TryGetValue() directly. But it would work and would not have the run-time costs your current work-around has.

One significant point missing from your question is, how does code use your wrapper implementation? It's hard to see how this would be an important strategy to use broadly. It's too fragile and/or fragmented, depending on which version of your implementation you're using. So presumably you have some very specific scenario in which you feel this approach has value. It seems to me it would be more fruitful to post a question describing that specific scenario, explaining why the normal dictionary-based implementations don't work for you, and asking for help addressing that issue, in a manner different from the approach you're currently taking.