I\'ve seen a number of people suggest that you should encapsulate generic types with a class closer to your domain, for example Steve and Nat suggest in Growing Object-Orien
Because leaving type parameter as it is isn't really DRY. Consider this class:
class Muffin {
List _peopleWhoLikeMuffins = new List();
public Muffin(List peopleWhoLikeMuffins) {
_peopleWhoLikeMuffins = peopleWhoLikeMuffins);
}
public void AddMuffinLiker(string p) {
_peopleWhoLikeMuffins.Add(p);
}
}
It's really short and only contains basic functionality, but I had to use string - genertic type parameter - four times. And it will always be the same. And if I decide to go to change the type later, I'll have to replace all four occurences.
In real world scenarios we are talking hundreds, not 4. So, it's not a no-brainer to always incapsulate it, but it's definitely worth considering.
Now, my example is not very good (and not only because of silly names), but you get the idea - you'll have a lot of field and variables declaration and instantiation, and every time you'll have to pass a type parameter which will always be the same throughout your codebase unless your other classes are also generic.
Another advantage of this is that you'll have much less work if you ever need to add some additional state/behavior to your collection.
That all being said, I myself don't use this kind of abstraction very often.