Question

我总是编写引用一个对象作为单个类的编码，如果我想获取该类的集合，我只使用Get（）并返回列表。

public abstract class Customer
{
   private Int32 customerID;
   private String customerName;

   public abstract List<Customer> Get();
   public abstract bool Add();
   public abstract bool Update();
   public abstract bool Delete();
}

现在......我收到了其他关于此的评论，我应该创建另一个集合类来满足这个需求。我也特别在ORM（对象关系映射）的东西中看到过这个但是不是太多了吗？

所以它会是这样的：

public abstract class CustomerCollection
{    
   public abstract List<Customer> Get();
   public abstract bool Add();
   public abstract bool Update();
   public abstract bool Delete();
}

你对此有何看法？

由于

Answer 1

听起来你问的是，使用List<Customer>等内置集合是否更好，或创建自己的CustomerList类。与此问题分开，重要的是要确保您的单Customer课遵循良好的OO设计（并且您的Get()方法似乎......奇怪，至少）。

除此之外，我的方法是始终使用内置集合 interfaces ，而不是内置集合类。例如，任何返回Customer s集合的函数都应返回IEnumerable<Customer>，ICollection<Customer>或IList<Customer>，具体取决于您是否需要能够循环执行他们，计算他们，或分别以随机顺序挑选出来。

然后您的初始实现可以像现在一样返回List<Customer>，但如果您需要更多特定功能，可以在以后轻松地将其替换为其他集合。

已更新：如果您真的关心以后扩展它的想法，您还可以创建一个界面：

public interface ICustomerList : IList<Customer> { }

你的默认实现只是一个空子类：

public class CustomerList : List<Customer>, ICustomerList { }

然后让所有类返回ICustomerList（您实际上会返回CustomerList个实例）。然后在将来的版本中，您可以扩展ICustomerList接口以添加新方法，而不会破坏当前只是像列表一样使用它的任何代码。

请注意，我没有测试过这种方法。 YMMV。

但最重要的是，除非添加新功能，否则不应创建新类。推论：始终返回一个暴露您愿意支持的最低功能的界面。

Answer 2

当涉及到使用容器/集合类时，我认为这是个人喜好的问题。就个人而言，我喜欢你能够将CRUD方法从其他模型类中分离到特定容器/集合类的方式。对我来说，不要将这些方法放在Customer模型类上更有意义。

Answer 3

方法名称Get（）是不明确的 - 像Customer.AsList（）这样的东西会更有意义。或者只是在需要时创建一个包含该Customer的新List，而不是为它创建一个方法。

单班和班级收藏

3 个答案: