Single class and Class Collection

Question

Hi there

I'm always coding referencing an object as a single class and if I want to get the collection of that class I just used the Get() and return as a list.

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();
}

Now ... I've been received comments from other about this that I should create another class for collection to cater this. I've also seen this especially in ORM (Object Relation Mapping) stuff but isn't that too much?

So it will be something like this:

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

What is your thought about this?

Thanks

Answer 1

The method name Get() is ambiguous -- something like Customer.AsList() would make more sense. Or simply just creating a new List containing that Customer when you need one, instead of making a method for it.

Answer 2

It sounds like you're asking if it's better to use built-in collections like List<Customer>, or to create your own CustomerList class. Separately from this question, it is important to make sure your single Customer class follows good OO design (and your Get() method seems... strange, at the least).

Setting that aside, my approach is to always use the built-in collection interfaces, not built-in collection classes. For example, any function that returns a collection of Customers should return an IEnumerable<Customer>, ICollection<Customer> or perhaps IList<Customer>, depending on whether you need to be able to just loop through them, count them, or pick ones out in random order, respectively.

Then your initial implementation can just return List<Customer> as you do now, but you can easily replace it with a different collection later if you need more specific functionality.

Updated: If you're really concerned with the idea of extending it later, you could also create an interface:

public interface ICustomerList : IList<Customer> { }

And your default implementation would be just an empty subclass:

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

And then have all your classes return ICustomerList (you would actually return CustomerList instances). Then in a future version you can extend the ICustomerList interface to add new methods without breaking any code that currently just consumes it like a list.

Note that I haven't tested this approach. YMMV.

Bottom line, though, is that you shouldn't create a new class unless it adds new functionality. Corollary: Always return an interface that exposes the minimum functionality you are willing to support.

Answer 3

When it comes to using container/collection classes I think it's a matter of personal preferences really. Personally, I like the way you are able to seperate the CRUD methods to a specific container/collection class from the other model classes. It just makes more sense to me not to put such methods on the Customer model class.