换句话说，使用是否正确：

public class CustomerList : System.Collections.Generic.List<Customer>
{
    /// supposed to be empty
}

代替：

using CustomerList = System.Collections.Generic.List<Customer>

我宁愿使用第一种方法，因为我只定义一次CustomerList，而每次需要客户列表时，我总是使用相同的类型。另一方面，使用名称别名方法不仅迫使我不得不在任何地方重新定义它，而且每次有人想要使用它时都可以给它一个不同的别名(想像一个大团队)，从而导致代码可读性较差。

请注意，在这种情况下，这样做的目的绝不是扩展类，而只是创建一个别名。

解决方案

好吧，除非我们要向基类添加一些功能，否则创建包装对象是没有意义的。如果确实需要，我会选择第二个，但是为什么不创建一个变量呢？

List<Customer> customerList = new List<Customer>();

这是"取决于"问题之一。

如果我们需要的是一个除其他要求之外还可以充当"客户列表"的新类，那么继承就是这种方式。

如果我们只想使用客户列表，请使用变量。

如果我们只是想节省键入时间，请使用后者。这样就不会遇到任何奇怪的继承问题。

如果我们实际上想公开一个逻辑上不同的集合类型，则可以使用前一个集合，然后向其添加内容。

就个人而言，我只是使用List <Customer>并称之为一天。

我基本上同意艾德。如果我们不需要实际扩展泛型List构造的功能，只需使用泛型List：

List<Customer> customerList = new List<Customer>();

如果确实需要扩展功能，那么通常我们会考虑继承。

第三种可能性是，我们需要从通用列表构造中显着更改功能，在这种情况下，我们可能只想从IEnumerable继承。这样可以使该类在可枚举的操作(例如" foreach")中可用，但允许我们完全定义所有类的行为。

一个程序员节省的打字很可能是下一个程序员维护的噩梦。我要说的就是正确键入通用名称，正如这里许多人所说的那样。它更简洁，更准确地描述了代码的意图，并且将对维护程序员有所帮助。 (可能是我们，六个月后还有四个新项目！)

实际上，我们都不应该使用任何一个。根据框架设计指南的正确方法是使用或者继承公共API中的System.Collections.ObjectModel.Collection <T>(List <T>仅应用于内部实现)。

但是关于命名的特定问题，建议似乎是直接使用通用类型名称而不使用别名，除非我们需要向集合中添加功能：

Do return Collection<T> from object
  models to provide standard plain
  vanilla collection API.
  
  Do return a subclass of Collection<T>
  from object models to provide
  high-level collection API.

不要这样当人们阅读：

List<Customer>

他们立刻明白了。当他们阅读时：

CustomerList

他们必须去弄清楚什么是CustomerList，这会使代码更难阅读。除非我们是唯一在代码库上工作的人，否则编写可读代码是个好主意。

我同意不以这种方式使用别名。我们团队中的任何人都不应以介绍的方式使用别名；这不是提供别名的原因。此外，从泛型的工作方式来看，无论我们使用多少个列表类，都只有一个List类。

除了声明和使用List <Customer>外，我们最终还要将该列表传递给其他对象。避免传递具体的List <Customer>，而传递IList <Customer>或者ICollection <Customer>，因为这将使这些方法更具弹性并且更易于编程。

将来有一天，如果我们确实确实需要一个CustomerList集合类，则可以在其上实现ICollection <Customer>或者IList <Customer>，并继续将其传递给那些方法，而无需对其进行更改甚至不了解。