C#中返回集合时如何处理协方差？

Question

我在返回集合和协方差方面遇到问题，我想知道是否有人有更好的解决方案。

场景是这样的：

我有 2 个版本的实现，我想保持版本实现完全独立（即使它们可能具有相同的逻辑）。在实现中，我想返回一个项目列表，因此在界面中，我将返回项目的界面列表。但是，在接口的实际实现中，我想返回该项目的具体对象。在代码中，它看起来像这样。

interface IItem
{
    // some properties here
}

interface IResult
{
    IList<IItem> Items { get; }
}

然后，将有 2 个命名空间，它们具有这些接口的具体实现。例如，

命名空间 Version1

class Item : IItem

class Result : IResult
{
    public List<Item> Items
    {
        get { // get the list from somewhere }
    }

    IList<IItem> IResult.Items
    {
        get
        {
            // due to covariance, i have to convert it
            return this.Items.ToList<IItem>();
        }
    }
}

命名空间 Version2 下将会有相同事物的另一个实现。

为了创建这些对象，将有一个工厂来获取版本并根据需要创建适当的具体类型。

如果调用者知道确切的版本并执行以下操作，则代码可以正常工作

Version1.Result result = new Version1.Result();
result.Items.Add(//something);

但是，我希望用户能够执行类似的操作。

IResult result = // create from factory
result.Items.Add(//something);

但是，由于它已转换为另一个列表，因此添加不会执行任何操作，因为该项目不会被添加回原始结果对象。

我可以想到一些解决方案，例如：

1. 我可以同步两个列表，但这似乎是额外的工作
2. 返回 IEnumerable 而不是 IList 并添加创建/删除集合的方法
3. 创建一个采用 TConcrete 和 TInterface

I 的 自定义集合理解为什么会发生这种情况（由于类型安全），但我认为没有一个解决方法看起来非常优雅。有人有更好的解决方案或建议吗？

提前致谢！

更新

经过更多思考后，我想我可以执行以下操作：

public interface ICustomCollection<TInterface> : ICollection<TInterface>
{
}

public class CustomCollection<TConcrete, TInterface> : ICustomCollection<TInterface> where TConcrete : class, TInterface
{
    public void Add(TConcrete item)
    {
        // do add
    }

    void ICustomCollection<TInterface>.Add(TInterface item)
    {
        // validate that item is TConcrete and add to the collection.
        // otherwise throw exception indicating that the add is not allowed due to incompatible type
    }

    // rest of the implementation
}

那么我可以

interface IResult
{
    ICustomCollection<IItem> Items { get; }
}

then for implementation, I will have

class Result : IResult
{
    public CustomCollection<Item, IItem> Items { get; }

    ICustomCollection<TItem> IResult.Items
    {
        get { return this.Items; }
    }
}

这样做，如果调用者正在访问 Result 类，它将通过 CustomCollection.Add(TConcrete item)这已经是 TConcrete 了。如果调用者通过 IResult 接口访问，它将通过 customCollection.Add(TInterface item) 进行验证并确保类型实际上是 TConcrete。

我会尝试一下，看看这是否有效。

Answer 1

您面临的问题是因为想要公开一个类型（除其他外）“您可以向我添加任何 IItem”，但它实际上要做的是“您只能添加 >物品给我”。我认为最好的解决方案是实际公开 IList。无论如何，使用它的代码必须知道具体的 Item 是否应该将它们添加到列表中。

但如果你真的想这样做，我认为最干净的解决方案是 3.，如果我理解正确的话。它将成为 IList 的包装器，并将实现 IList。如果您尝试将非 TConcrete 的内容放入其中，它将引发异常。

Answer 2

对布伦特的评论+1：返回不可修改的集合并提供类的修改方法。

只是重申为什么你不能让 1 以可解释的方式工作：

如果你尝试添加到 List 元素，该元素仅实现 IItem 但不是类型 (或派生自）项目，您将无法将此新项目存储在列表中。由于结果接口的行为将非常不一致 - 一些实现 IItem 的元素可以很好地添加，但 sime 会失败，并且当您将实现更改为 version2 时，行为也会改变。

简单的修复方法是将 IList 存储在 List 中，但直接公开集合需要仔细考虑。

Answer 3

问题在于 Microsoft 使用一个接口 IList来描述可以附加的集合和不能附加的集合。虽然理论上一个类可以实现 IList；以可变的方式并实现 IList以不可变的方式（前一个接口的 ReadOnly 属性将返回 false，而后者将返回 true），类无​​法指定它实现 IList一种方式，并且 IList其中 cat:T，另一种方式。我希望 Microsoft 能够将 IList制作为 IList。列表实现 IReadableByIndex、IWritableByIndex、IReadWriteByIndex、IAppendable和 ICountable，因为这些允许协变和逆变，但他们没有。自己实现此类接口并为它们定义包装器可能会有所帮助，具体取决于协方差的帮助程度。