Is it good practice to use plurality to name collections? [closed]

Question

Simply put, is it a good idea to name collections and composite objects using plurality?

class PandaBears {
   PandaBear[] bears;

   class PandaBear {
   }
}

My concern is that the class names are quite similar. On the other hand, PandaBearList reveals the implementation, but is more easily distinguishable.

Answer 1

I would prefer PandaBearCollection. A class name that is a countable noun just agrees better with the fundamental metaphor of OOP, an "object".

For example, try describing the signature of the following two functions:

void func(PandaBearCollection collection1, PandaBearCollection collection2);
void func(PandaBears pandaBears1, PandaBears pandaBears2);

The first one would naturally be: "A function that takes two collections of panda bears".

What would be the second one? "A function that takes two panda bears"? No, it just doesn't work.

Answer 2

I would avoid plurality.

If you don't want to include the suffix List, you could always use the suffix Collection which is a standard convention and does not reveal the implementation details. Of course this depends on the language you are using.

There is also a C#-specific work-around which I like to use if the structure is not very complex. You can avoid creating the Collection class at all, by declaring all the methods as extension methods of the related IEnumerable<T>. So, in this case, you could declare extension methods on IEnumerable<PandaBear>, provided that your collection does not have other private variables.