继承列表实施集合是一个坏主意吗？

Question

我曾经读过 Imaar Spaanjars 写的一篇关于如何构建 3 层应用程序的文章。 (http://imar. spaanjaars.com/416/building-layered-web-applications-with-microsoft-aspnet-20-part-1），它已经成为我编码的基础一段时间了。

因此，我像他一样通过继承 List 来实现集合。因此，如果我有一个名为 Employee 的类，为了实现一个集合，我还将有一个名为 Employee 的类，如下所示。

class Employee
{
   int EmpID {get;set;}
   string EmpName {get;set;}  

}

class Employees : List<Employee>
{
   public Employees(){}
}

我从来没有真正质疑过这一点，因为它对我有用。但现在我开始尝试一些事情，我不确定这是否是正确的方法。

例如，如果我想从Employees 获取子集，例如

 Employees newEmployees = (Employees) AllEmployees.FindAll(emp => emp.JoiningDate > DateTime.Now);

This throws a System.InvalidCastException 。但是，如果我使用以下内容，则没有问题。

List<Employee> newEmployees = AllEmployees.FindAll(emp => emp.JoiningDate > DateTime.Now);

那么如何实现Employees，这样我就不必在DAL 或BLL 中显式使用List 了？或者也许我该如何摆脱 InvalidCastexception？

Answer 1

我不会继承 List - 它引入了类似的问题，并且没有真正的帮助（因为没有 virtual 方法可以覆盖）。我要么使用 List （或更抽象的 IList），要么引入多态性 Collection 有虚拟方法。

作为注释；对于像 FindAll 这样的东西，您还可能会找到有用的对应项 LINQ 选项（例如 .Where()）；最值得注意的是，它们适用于任何 IList（或 IEnumerable），而不仅仅是 List。 和子类。

Answer 2

通过子类化 List 可以获得什么好处？如果它没有添加任何内容，那么它就是不必要的代码膨胀。如果您没有显示方法或通过此处未显示的构造函数强制执行契约，那么这可能是子类化的正当理由。

在解决转换问题方面，您无法从 List 向下转换为 Employees，因为 List 不会继承自Employees。如果您需要返回具有您的条件的员工，那么您最好封装该调用并将返回的列表项插入到您自己的员工对象中。这对我来说似乎是浪费时间，除非像我上面所说的那样，您有充分的理由对 List 进行子类化。

就我个人而言，我会尽可能尝试使用 IList 并且不会创建子类，除非它们有存在的理由。

Answer 3

一个简单的经验法则是从组合开始（例如将员工包裹在通用集合中）而不是继承。从基于继承的设计开始，你就会陷入困境。组合更加灵活和可修改。

Answer 4

我个人会将列表存储为容器对象的成员，并在必要时提供列表本身的 get 访问器。

class MyCollection<T> 
{
    List<T> _table;
    public List<T> Table
    {
        get
        {
            return _table;
        }
    }
    // ... other access/utility functions common for all tables 
    //     (CRUD for example)
}

class Employees : MyCollection<Employee>
{
    // ... yet more methods 
}

我必须承认，我这样做是为了为自己提供以下方法：

T FindById(int id);
void Add(T entity);
void Remove(T entity);

在基类上以及：

T[] GetEmployeesBy(your_filter_here);

我（仍然）使用.net 2.0，所以我没有 linq - 也许这就是这里的原因。