Reputation: 158021
When reading this question I started to wonder a bit. Say you have these two:
class ProductCollection : ICollection<Product>
class ProductList : IList<Product>
What would you call one that were an IEnumerable<Product>
?
class Product--- : IEnumerable<Product>
Before I read that other question I might have called it a ProductCollection
actually, but taking the new info into account, that would have been a bit misleading since it does not implement ICollection<Product>
. Could you call it Products
?
var products = new Products(); // products is/are products
Almost works but sounds a bit strange... What would you call it?
Upvotes: 8
Views: 3266
Reputation: 147280
You generally do not base the name of a class off any interface it implements. (Which one do you choose when there are multiple ones, for a start?) It is quite typical to base it off an inherited class, but more often simply on the purpose of the class, and certainly not the interface. (The interface might be named after the class, if anything.)
Your example is somewhat invalidated by the fact that a well-designed ProductCollection
should implement ICollection<Product>
and IEnumerable<Product>
while a well-designed ProductList
should implement both those interfaces as well as IList<Product>
.
If you look in the BCL of the .NET Framework, you should notice that this is precisely the case. The List<T>
class implements all three interfaces, as does the Collection<T>
class (though note that in the general case a 'collection' need not implement IList<T>
).
Upvotes: 8
Reputation: 19263
I would say Collection. It might suggest a ReadOnlyCollection or ObservableCollection , but it describes the class well. It is after all a collection of products (whatever the underlying type may be).
To solve this question and the other question, use this ;)
http://www.classnamer.com/
Upvotes: -1
Reputation: 19765
Like kek444 I think I'd have to ask what else does it do? It implements IEnumerable<> but that's not all it does, or else you wouldn't need the class right? It is a collection? Does it transform one enumerable to another (alter order, selection, generation, etc)?
Upvotes: 0
Reputation: 532435
If it only implements IEnumerable<Product>
, then I would name it ProductEnumeration
, but I would feel free to name an instance of it products
. On the other hand, I don't recall ever creating a class that only implemented IEnumerable<T>
. Doesn't seem to be much point if you can't add stuff to it and if you can, then I'd derive from one of the collection classes that implements IEnumerable<T>
and inherit that behavior, too.
If I were returning an enumeration of Product entities, I'd simply return it as IEnumerable<Product>
without having a special class.
Upvotes: 5
Reputation: 116674
In almost every case I can think of from my own experience, I haven't had to think of a name. The compiler does it for me, because I write an iterator method instead of writing a class by hand. And for the method name, it seems natural to just make it a plural word describing the sequence.
Upvotes: 0
Reputation: 14111
It would depend upon the context, for example, it could be a ProductsCatalog
(implying the read-only nature of IEnumerable
).
More generally, it could be ProductsView
. Of course, the Products
fetched would be modifiable, but I feel it "sounds" appropriate nevertheless.
Upvotes: 2
Reputation: 10290
The problem here is that List or Collection impose they behave that way. But IEnumerable is very generic, not only in the C# meaning of generic. Every implementation can be behind it.
Some suggestions:
Upvotes: 1
Reputation: 158309
If you look at the types in the .NET Framework that implements IEnumerable<T>
, I would say that the most common suffix is Collection
, followed by the plural form of what the list contains. Then there are a number of "special cases" (such as Queue
and Stack
). I would personally vote for Collection
as a first-hand choice.
Upvotes: 0