您接受接口作为构造函数参数吗？

Question

Krzysztof 的建议是否适用于构造函数？ 如果是这样，您如何正确实施？

我们建议使用 Collection、ReadOnlyCollection 或 KeyedCollection 作为输出和属性，并使用接口 IEnumerable、ICollection、IList 作为输入。

例如，

public ClassA
{
    private Collection<String> strings;
    public Collection<String> Strings { get { return strings; } }
    public ClassA(IEnumerable<String> strings)
    {
        this.strings = strings; // this does not compile
        this.strings = strings as Collection<String>; // compiles (and usually runs?)
    }
}

Answer 1

你应该避免沮丧； 在您的示例中，我建议您的构造函数参数的类型应该与您的成员数据的类型匹配（应该相同）（即任一 Collection 或 IEnumerable）。

或者有 Marc 的解决方案，这是不同的：因为 Marc 的解决方案意味着您的成员数据不仅是不同的类型，而且还是不同的实例（即，如果您修改成员数据，那么您正在修改原始集合的副本，不编辑原始集合本身；类似地，如果在创建副本后修改了原始集合，则您的本地副本/成员数据不包括对原始集合的后续更改）。

Answer 2

您不应该使用 as 版本 - 您应该接受并存储可重复的内容，例如 IList，或者创建一个新的本地数据集合：

this.strings = new Collection<string>();
foreach(string s in strings) { this.strings.Add(s); }

实际上，我自己会使用 List； 那么你可以这样做（尽管这不是使用 List 的原因）：

this.strings = new List<string>(strings);

Answer 3

我认为如果可能的话应该避免沮丧。 如果该类将输入存储为具体类“Collection”（这意味着该类与“Collection”一起使用，那么我认为只接受“Collection”类型的输入而不是接口对应项更自然。

这将向下转型的责任（如果需要）转移给消费者，如果他向下转型，消费者应该知道他在做什么。

另一方面，我想说接受输入作为接口比具体类更好，因为它允许灵活性。然而，这需要类的内部依赖于接口而不是具体的类（因此在示例中，成员变量将是 IEnumerable 而不是 Collection），

我同意 yapiskan 的观点。 Marc 的解决方案实际上通过创建输入的副本来改变用法，因此责任也发生了变化：

之前：输入始终在使用者和此类之间共享，因此，对输入的更改是在消费者和此类之间“共享”的。消费者和此类

之后：在调用构造函数之后，此类对输入的理解与消费者分离。

Answer 4

如果您存储的是 Collection，那么我更喜欢将 ICollection 作为输入。

Answer 5

为什么不接受 IEnumerable 类型的参数并将其强制转换为检索？

public ClassA
{
    private IEnumberable<String> strings;

    public Collection<String> StringCollection {
        get { return (Collection<String>) strings; }
    }

    public ClassA(IEnumerable<String> strings)
    {
        this.strings = strings; 
    }
}

Answer 6

我有点同意佩奇的观点。

我同意您应该将 IEnumerable 作为输入传递（这样您就支持任何可枚举集合）。

但是你上面对 StringCollection 属性所做的事情对我来说没有意义 - 你正在向下转型，这是行不通的。

-马特

Answer 7

这可能是为了不暴露太多的实现。 理想情况下，如果您正在设计公共 API，您应该只公开最少的实现。 如果您返回完整的 List 接口，那么公共 API 的用户将有多种方式以您可能不希望的方式扰乱类的内部结构。

- - 编辑 - -