Generic Collection Pattern

  • Thread starter Thread starter Brian Richards
  • Start date Start date
B

Brian Richards

Without generics generally I'd dervie from CollectionBase to create typed
collections. Generics mostly fill in this gap except that there are no
virtual methods on List<T> so we can no longer notify other object when a
collection changes during add, remove and set operations. I was curious how
Others were getting around this problem? I thought of doing something like:

class MyCollection : IList<T>, ICollection<T>
{
private List<T> m_list;
}

Then simply operate on m_list for each of the implementation of the
interfaces. I feel like there's a simpler solution out there that I'm not
seeing.

Thanks
 
"Brian Richards" <[email protected]> a écrit dans le message de (e-mail address removed)...

| Without generics generally I'd dervie from CollectionBase to create typed
| collections. Generics mostly fill in this gap except that there are no
| virtual methods on List<T> so we can no longer notify other object when a
| collection changes during add, remove and set operations. I was curious
how
| Others were getting around this problem? I thought of doing something
like:

Take a look at BindingList<T>.

Joanna
 
Brian said:
Without generics generally I'd dervie from CollectionBase to create typed
collections. Generics mostly fill in this gap except that there are no
virtual methods on List<T> so we can no longer notify other object when a
collection changes during add, remove and set operations. I was curious how
Others were getting around this problem?
Click to expand...

I asked a similar question here: <http://tinyurl.com/lntcp>
 
Just hide the base class's method with the new operator. Example (from a
class the inherits System.Collections.Generic.Dictionary):

new virtual public void Add(string key, T value)
{
base.Add(key, value);
// add an event here if you wish.
}

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Development Numbskull

Abnormality is anything but average.
 
That's not such a hot idea if you intend passing the container around cast
as an interface or as an instance of the base class; if you can't override,
then you can /only/ change the behaviour when code knows the object /as/ the
new class. Personally I wouldn't advise this.

Marc
 
Back
Top