继承List <T>来实现集合是一个坏主意？
我曾经阅读过Imaar Spaanjars关于如何构建3层应用程序的文章。 （http://imar.spaanjaars.com/416/building-layered-web-applications-with-microsoft-aspnet-20-part-1），它已经形成了我现在编码的基础。
因此，我通过继承List<T>实现集合。 所以，如果我有一个名为Employee的类，为了实现一个集合，我还将拥有一个类Employees，如下所示。
class Employee
{
int EmpID {get;set;}
string EmpName {get;set;}
}
class Employees : List<Employee>
{
public Employees(){}
}
我从来没有真正质疑这一点，因为它为我做的工作。 但是现在我开始尝试几件事情，我不确定这是否是正确的方法。
例如，如果我想从雇员那里获得一个子集，比如
Employees newEmployees = (Employees) AllEmployees.FindAll(emp => emp.JoiningDate > DateTime.Now);
这将引发System.InvalidCastException。 但是，如果我使用以下，则不存在问题。
List<Employee> newEmployees = AllEmployees.FindAll(emp => emp.JoiningDate > DateTime.Now);
那么，如何实现员工，以便我不必在我的DAL或BLL中显式使用List<Employee> ？ 或者，也许我该如何摆脱InvalidCastexception？
我不会从List<T>继承 - 它引入了这些问题，并没有真正的帮助（因为没有virtual方法可以覆盖）。 我要么使用List<T> （或更抽象的IList<T> ），要么引入多态性Collection<T>具有虚拟方法。
作为一个说明; 像FindAll这样的东西，你也可以找到LINQ选项（比如.Where() ）有用的对应项; 最值得注意的是，它们将适用于任何IList<T> （或IEnumerable<T> ），而不仅仅是List<T>和子类。
通过子类别List<Employee>获得什么好处？ 如果它什么都不加，那就没必要代码膨胀了。 如果你没有显示方法，或者通过你没有在这里显示的构造函数强制执行契约，那么这可能是子类的有效理由。
在解决你的投射问题方面，你不能从List<Employee>向下转换为Employees作为List<Employee>不能从Employees继承。 如果您需要按照您的条件返回Employees，则最好封装调用并将返回的列表项插入到您自己的Employees对象中。 这对我来说似乎是浪费时间，除非像我上面所说的那样，你有充足的理由去分类List<Employee> 。
就个人而言，我会尝试尽可能使用IList<T> ，除非有理由存在，否则不要创建子类。
一个简单的经验法则是从COMPOSITION开始（例如，围绕一个通用集合包装员工）而不是继承。 以继承为基础的设计开始将自己打造成一个角落。 构图更加灵活和可修改。
链接地址: http://www.djcxy.com/p/53867.html上一篇: Inheriting List<T> to implement collections a bad idea?