Multiple generic collection base classes



  • I work in an ASP.Net, C# shop.  Someone I work with is going through the system doing "best practices cleanup."  I don't think that means what he thinks that means.  A class used to be defined like:

    public class UserCollection : CollectionBase, IPersistable

    Seems reasonable...  But he's changed many, many classes to this:

    public sealed class UserCollection : CollectionBase, IPersistable, ICollection<User>, IList, IList<User>

    On top of that, the consistent data member in these classes is an ArrayList called _data.  This object is sometimes used, sometimes not.  Some implementations define a GetEnumerator function (part of the ICollection interface) to return _data.GetEnumerator(), even though _data is never assigned any values.  You can imagine this causes problems... So WTF aside, does anyone know of any side effects of using 4 different collection base classes/interfaces?  After reading through a couple of these classes and needing to walk away to avoid passing out, I don't have the energy to dig into the interfaces and how they work, but it seems like you could end up with more than one place to store data and more than one way to retrieve it.  So, depending on how you use the object, you could store to one place and read from another (like my example, but not so explicitly).  Is that right?  Do I need to beat this guy with the biggest .Net book I can find?  Is it just harmless?



  • Why would you not just define it as UserCollection : Collection<User>, IPersistable?  Collection<T> includes all the other interfaces so it makes it much easier to define and maintain. 

     Personally, I create a custom generic collection class and inherit from that.  That way when I chose to implement filtering/sorting/searching I just have to change it in the base class and not have to revisit all my collections.



  •  That was kind of my thought exactly.  Involving multiple collection and/or generic collection bases just seems useless to me.  I'm definitely getting it fixed one way or another, I just wonder about anything strange that could be caused by including multiple different collection bases.



  • I don't think will cause any issues since there is only one base class (CollectionBase), the rest are just interfaces defining what methods and properties are implemented in the derived class.   It looks like a migration from .Net 1.1 to 2.0 to me.  Personally, I'd just take one collection at a time and upgrade it to a generic implementation and fix any code breakages.  Although without knowing the internals of the application, I don't know how much work a single upgrade could be. 

     


Log in to reply