避免泛型类型的模棱两可的调用错误答案

【问题标题】：Avoiding ambiguous invocation error with generic types避免泛型类型的模棱两可的调用错误
【发布时间】：2011-04-14 04:59:10
【问题描述】：

我正在制作一个双向字典类，以允许我在任一方向上进行快速查找。

我的班级看起来（部分）像这样：

public class DoubleDictionary<A,B>
{
    private Dictionary<A, B> _forward;
    private Dictionary<B, A> _backward;

    public A this[B b]
    {
        get { return _backward[b]; }
        set { _backward[b] = value; }
    }

    public B this[A a]
    {
        get { return _forward[a]; }
        set { _forward[a] = value; }
    }
}

我在这个例子中使用了数组索引运算符，但几乎每个方法都有两个通用版本。在 A == B 的情况下，除了效果很好。

如果我这样做了

var foo = new DoubleDictionary<int, int>();
int x = foo[3];

由于索引器不明确，它甚至无法编译。

我理解为什么编译器会出现这个问题，并且我同意它可能不合法。

假设我实际上有一个需要DoubleDictionary<int,int> 的有效用例，并且我任意选择数组索引应该访问正向字典。

我为解决所有这些问题而得出的解决方案是放弃为每个方向唯一命名的方法的光滑索引语法。这让它变得不那么神奇，也不那么有趣了。

有没有办法给编译器提示来解决歧义，而不必求助于唯一命名的方法？我真的很喜欢用重载来做这个的想法，并希望保持这种状态。我宁愿在课堂上这样做，这样调用者就不必担心它，但我想调用者必须做一些反射魔法才能让它工作。

如果不可能，我会很好地限制 A 不能与 B 相同。有没有办法将其编码，这样DoubleDictionary<int,int> 的声明就不会编译？我可以在构造函数中抛出异常，但如果它在编译时被捕获就更好了。

【问题讨论】：

“这让它变得不那么神奇，也不那么有趣了。”我认为它改进了设计并使 API 更加清晰。
公平点。我还是喜欢数组索引，因为感觉更像是 Dictionary 类的索引，非常简洁明了。

标签： c# generics overload-resolution

【解决方案1】：

好吧，如果允许的话，拥有两个索引器将是一个非常糟糕的设计。

有这本词典：

var foo = new DoubleDictionary<int, int>();
foo.Add(3, 4);
foo.Add(2, 3);

然后做：

foo[3]

您希望得到 2 个吗？还是4？为什么？

最好让 API 清晰。

【讨论】：

【解决方案2】：

您始终可以保留索引器，但将命名方法添加为辅助 API - 甚至可以通过扩展方法，这样您就可以通过添加 using 指令来发挥它们的作用...

【讨论】：

这似乎非常明智。当发生的事情很明显时，我会感到很神奇，但是当我需要它时，还有一种更明确的模式。听起来不错。

【解决方案3】：

没有任何方法可以按原样解决歧义，因为它是一个不允许您指定参数的索引器，并且在泛型约束中关联类型参数的唯一方法是通过继承。

我认为一个很好的折衷办法是使用索引器进行前向查找，使用类似GetKeyForValue(B value) 的方法进行后向查找。

【讨论】：