What are the recommendations for exposing a custom collection vs generic one? e.g
public class ImageCollection : Collection<Image>
{
...
}
public class Product
{
public ImageCollection {get; set;}
}
VS
public class Product
{
public Collection<Image> Images{get; set;}
}
What cases would you consider creating a custom collection? What are the pros and cons of each method?
I would go for the second one. The client code has to know the Image type anyway.
The first one only means more code.
The only reason to ever use Collection<T> is if you want to hook into the set of virtual methods which allows you to see all of the mutations to the underlying list. This allows you to do such operations as respond to deletes, implement events, etc ...
If you are not interested responding to or watching these collection modifications then a List<T> is a more appropriate type.
If you're building a public API, consider using a custom collection for the following advantages.
Extensibility - you can add features to your custom collection in the future without changing the API.
Backwards compatibility - you are free to change the internals of your collection class as you please, without breaking existing code that clients have programmed against the collection.
It's also easier to make potentially breaking changes with less impact. Perhaps later you decide you don't want it to be a Collection<Image>, but a different collection type - you can tailor your ImageCollection class to have the same methods as before, but inherit from something different - and client code will not be likely to break.
If it's just for internal use code, the decision is not necessarily as important, and you may decide to go with "simpler is better".
An example off the top of my head is the ArcGIS Server API's from ESRI - they use custom collections in their APIs. We also use custom collections in our API's mostly for these reasons.
The main reason I can think of is that you might want to have some methods specific to a collection of images that operate on that collection itself. Then I would use an ImageCollection class to contain those methods. Classic encapsulation.
Also, just an aside, you should really only expose a getter for that collection, and initialize a readonly backing field with the actual collection. You probably want people to add/remove items to the collection, not replace the entire thing:
class Product {
private readonly Collection<Image> _images;
public Product() { _images = new Collection<Image>(); }
public Collection<Image> Images { get { return _images; } }
}
-Oisin
In general, it's best to expose one of the interfaces, such as IEnumerable<T>, ICollection<T> or IList<T> instead of a concrete class.
This provides you with much more flexibility in terms of changing your internal API. IEnumerable<T>, in particular, lets you potentially modify your internals later to allow streaming of results, so is the most flexible.
If you know the expected usage patterns of your "collections", you should expose the appropriate API that provides the least constraints on you in the future. If, for example, you know that people just need to iterate your results, expose IEnumerable<T>, so you can change to ANY collection later, or even switch to just using yield return directly.
I prefer to have a public generic property to make the internals extensible, but a private field would be the custom one with the actual functionality.
It usually looks like this:
public interface IProduct
{
ICollection<Image> Images { get; }
}
public class Product : IProduct
{
private class ImageCollection : Collection<Image>
{
// override InsertItem, RemoveItem, etc.
}
private readonly ImageCollection _images;
public ICollection<Image> Images
{
get { return _images; }
}
}
I also often make the custom collection class nested inside a different class, which allows me to modify some private members of the parent class during add/remove.