用C#封装集合

Question

从 3.0 开始，C# 就有了很好的语法糖，比如自动属性，这大大简化了封装原则的实现。如果您将它与原子值一起使用，这很好，因此您可以像这样替换封装模式：

private string _name;

public string Name 
{
  get { return _name; }
  set { _name = value; }
}

仅用一行：

public string FirstName  { get; set; }

我非常喜欢这个很棒的功能，因为它节省了很多开发人员的时间。

---

但是，当您创建指向集合的属性时，情况就不那么好了。 通常我看到集合属性以两种方式之一实现。

1）根本不需要自动属性就能够使用字段初始值设定项：

private List<string> _names = new List<string>();

public List<string> Names
{
    get { return _names; }
}

2）使用自动属性。如果类只有一个构造函数，那么这种方法是可以的：

public List<string> Names { get; private set; }

public .ctor()
{
    Names = new List<string>();
}

但是，当您以这种方式处理像列表这样的可变集合时，您就破坏了封装，因为该属性的用户可以修改集合而不让容器知道（或者如果您忘记创建集合，甚至可以替换集合）设置器私有）。

对我来说，关于封装集合模式，集合封装的正确实现应该是这样的：

private readonly List<string> _names = new List<string>();

public ICollection<string> Names
{
    get { return new ReadOnlyCollection<string>(_names); }
}

public void Add_Name(string name)
{
    _names.Add(name);
}

public void Remove_Names(string name)
{
    _names.Remove(name);
}

public void Clear_Names()
{
    _names.Clear();
}

老实说，我不记得我是否在实际代码中遇到过这种实现，即使是在框架源代码中。我认为这是因为人们很懒，避免编写如此大量的代码只是为了使封装更强一点。

我想知道为什么 C# 团队不提供一些清晰且简单的方法来定义集合自动属性，以便开发人员可以满足他们的懒惰仍然创建健壮的代码？

Answer 1

TL;DR，C# 编译器没有自动集合，因为有很多不同的公开集合的方式。当公开一个集合时，您应该仔细考虑您希望如何封装该集合并使用正确的方法。

---

C# 编译器提供自动属性的原因是因为它们很常见并且几乎总是以相同的方式工作，但是当您发现处理集合时情况很少如此简单 - 有许多不同公开集合的方法，正确的方法总是取决于具体情况，仅举几例：

1）可以更改的集合

通常没有真正需要对公开的集合施加任何实际限制：

public List<T> Collection
{
    get
    {
        return this.collection;
    }
    set
    {
        if (value == null)
        {
            throw new ArgumentNullException();
        }
        this.collection = value;
    }
}
private List<T> collection = new List<T>();

这可能是一个好主意确保集合永远不为空，否则你可以只使用自动属性。除非我有充分的理由想要对我的集合进行更多封装，否则为了简单起见，我总是使用此方法。

2) 可以修改但不能交换的集合

您可以按照自己喜欢的方式进行编码，但想法是相同的 - 公开的集合允许修改项目，但底层集合本身不能被另一个集合替换。例如：

public IList<T> Collection
{
    get
    {
        return this.collection;
    }
}
private ObservableCollection<T> collection = new ObservableCollection<T>();

当消费者处理可观察集合之类的事情时，我倾向于使用这种简单的模式应该能够修改集合，但我已经订阅了更改通知 - 如果您让消费者交换整个集合，那么您只会引起头痛。

3) 公开集合的只读副本

您经常希望阻止使用者修改公开的集合 - 通常您确实希望公开类能够修改该集合。执行此操作的一个简单方法是公开集合的只读副本：

public ReadOnlyCollection<T> Collection
{
    get
    {
        return new ReadOnlyCollection<T>(this.collection);
    }
}
private List<T> collection = new List<T>();

这具有返回的集合永远不会更改的属性，即使底层集合发生更改也是如此。这通常是一件好事，因为它允许消费者迭代返回的集合，而不必担心它可能会被更改：

foreach (var item in MyClass.Collection)
{
    // This is safe - even if MyClass changes the underlying collection
    // we won't be affected as we are working with a copy
}

但这并不总是预期（或期望）的行为 - 例如 Controls 属性 无法以这种方式工作。您还应该考虑到以这种方式复制许多大型集合可能效率低下。

当公开只读集合时，请始终注意控件中的项目仍然可以修改。同样，这可能是一件好事，但如果您希望公开的集合“完全”不可修改，那么请确保集合中的项目也是只读/不可变的（例如System.String） 。

4) 可以修改的集合，但只能以某种方式修改

假设您想要公开一个可以添加项目但不能删除项目的集合？您可以在公开类本身上公开属性：

public ReadOnlyCollection<T> Collection
{
    get
    {
        return new ReadOnlyCollection<T>(this.collection);
    }
}
private List<T> collection = new List<T>();

public AddItem(T item);

但是，如果您的对象有许多这样的集合，那么您的界面很快就会变得混乱和混乱。另外，我发现这种模式有时可能违反直觉：

var collection = MyClass.Collection;
int count = collection.Count;

MyClass.AddItem(item);

Debug.Assert(collection.Count > count, "huh?");

它需要付出更多的努力，但在我看来，一种更简洁的方法是公开一个自定义集合，该集合封装了您的“真实”集合以及有关该集合如何可以和不可以的规则被更改，例如：

public sealed class CustomCollection<T> : IList<T>
{
    private IList<T> wrappedCollection;

    public CustomCollection(IList<T> wrappedCollection)
    {
        if (wrappedCollection == null)
        {
            throw new ArgumentNullException("wrappedCollection");
        }
        this.wrappedCollection = wrappedCollection;
    }

    // "hide" methods that don't make sense by explicitly implementing them and
    // throwing a NotSupportedException
    void IList<T>.RemoveAt(int index)
    {
        throw new NotSupportedException();
    }

    // Implement methods that do make sense by passing the call to the wrapped collection
    public void Add(T item)
    {
        this.wrappedCollection.Add(item);
    }
}

使用示例：

public MyClass()
{
    this.wrappedCollection = new CustomCollection<T>(this.collection)
}

public CustomCollection<T> Collection
{
    get
    {
        return this.wrappedCollection;
    }
}
private CustomCollection<T> wrappedCollection;
private List<T> collection = new List<T>();

公开的集合现在封装了我们关于如何修改集合和不可以修改集合的规则，并且还立即反映对基础集合所做的更改（这可能是好事，也可能不是好事）。对于大型集合来说，它也可能更有效。

Answer 2

private IList<string> _list = new List<string>();

public IEnumerable<string> List
{
  get
  {
    ///return _list;
     return _list.ToList();
  }
}

Answer 3

每当我必须公开一个集合时，我倾向于使用 IEnumerable 但显然您不能使用自动属性来执行此操作。

我真正希望看到在 .NET 中实现的一个解决方案是不可变集合的概念。这确实可以解决您正在谈论的问题，因为自动属性可以这样完美地工作：

 public ImmutableList<Foo> {get; private set; }

任何以任何方式修改列表的人都会获得 ImmutableList 的新实例，而不是原始列表本身。

您当然可以实现自己的 ImmutableList 但我觉得 .NET Framework 不包含这种元素有点奇怪。

Answer 4

公开 ICollection 并不是一个好主意，因为它允许添加和删除操作。

 public sealed class CollectionHolderSample
    {
        private readonly List<string> names;

        public CollectionHolderSample()
        {
            this.names = new List<string>();
        }

        public ReadOnlyCollection<string> Items
        {
            get
            {
                return this.names;
            }
        }

        public void AddItem(string item)
        {            
            this.names.Add(item);
        }
    }

编辑：

正如您提到的Add()和来自显式的 Remove() 方法ReadOnlyCollection.ICollection 实现将抛出 NotSupportedException 异常，因此集合是只读的。

另外，为了确保后台集合确实是只读的，您可以检查 IsReadOnly 属性。

MSDN 说：

ReadOnlyCollection.ICollection.IsReadOnly 属性 true 如果
ICollection 是只读的；否则为假。在默认情况下
ReadOnlyCollection 的实现，此属性始终返回
正确。