Generics vs Individual classes

[Aidy]

In .net 1.1 we'd have a whole bunch of collections for each of our classes.
So we'd have "ProductCollection", "UserCollection" etc etc, each a
strongly-typed collection for that user.

I know in 2.0 we can use generics, but I'm looking for opinions on using
Generics over the method mentioned above. I know it'll cut down on the
coding and number of classes, but is;

Collection<Product> products = ....
Collection<User> users = ....

better than

ProductCollection products = ....
UserCollection users = ....

Just wondering what people's thoughts are, I'm conscious that I might just
be seeking the known comfort of how things were done in 1.1.

 

[John Saunders [MVP]]

In .net 1.1 we'd have a whole bunch of collections for each of our
classes. So we'd have "ProductCollection", "UserCollection" etc etc, each
a strongly-typed collection for that user.

I know in 2.0 we can use generics, but I'm looking for opinions on using
Generics over the method mentioned above. I know it'll cut down on the
coding and number of classes, but is;

Collection<Product> products = ....
Collection<User> users = ....

better than

ProductCollection products = ....
UserCollection users = ....

Just wondering what people's thoughts are, I'm conscious that I might just
be seeking the known comfort of how things were done in 1.1.

If the individual collection types have no type-specific behavior, then they
already are, in effect, Collection<User>:

public class UserCollection : Collection<User>
{
}

This class has no specific behavior that isn't in the base class, so why not
use Collection<User> explicitly? If you need to add behavior later, you can
always refactor to use UserCollection.

 

[sloan]

If you need collection based specific methods, then you want to go ahead and
code up the

namespace Collections
{
public class EmployeeCollection : List < BusinessObjects.Employee >
{
}
}

That's it. A few lines of code, and you've got most of what you need.


I've discovered I'm inclined to go ahead and code up the actual collection
class, mainly for readability. And that off chance I'll add a collection
specific method.
But I couldn't argue very strongly for not pre-coding up the actual
collections either.
Its probably a matter of taste.




I found this interesting also:
http://www.mattberther.com/?p=592
Refactoring away external loops

 

[Kevin Spencer]

I've discovered I'm inclined to go ahead and code up the actual collection

class, mainly for readability. And that off chance I'll add a collection
specific method.

I take the same approach. It's more extensible.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[Aidy]

public class EmployeeCollection : List < BusinessObjects.Employee >

I think I'll do that. My other concern was that some of my collections will
need sollection-specific methods and properties and I was wanting to avoid
having most collections as a generic, then some collections as individual
classes so I can add one-off methods.

Thanks for the info guys, it's been helpful.