Run code when a collection is modified (items added or removed)

Question

I have a class that contains a list of objects. What's the best way to run some code in the class when the list is modified?

class MyManagerClass
{
    ArrayList list = new ArrayList(); // will likely be a different collection class
    private OnItemAddedToList(object o)
    {
        // how to call this?
    }

    private OnItemRemovedFromList(object o)
    {
        // how to call this?  
    }
}

Answer 1

Instead of using the ArrayList from System.Collections you should consider using the ArrayList from the C5 Generic Collection Library. It has events like CollectionChanged, ItemAdded etc.

Answer 2

The method I've been using so far is to make a private collection class derived from System.Collections.ObjectModel.Collection<T>, and call the methods directly in the overrides:

class MyManagerClass
{
    private class MyCollection : System.Collections.ObjectModel.Collection<object>
    {
        private MyManagerClass manager;

        private MyCollection(MyManagerClass manager)
        {
            this.manager = manager;
        }

        protected override void InsertItem(int index, object item)
        {
            base.InsertItem(index, item);
            manager.OnItemAddedToList(item);
        }

        protected override void SetItem(int index, object item)
        {
            object oldItem = (index < base.Count) ? base[index] : null;
            base.SetItem(index, item);

            if (oldItem != null) {
                manager.OnItemRemovedFromList(oldItem);
            }

            manager.OnItemAddedToList(item);
        }

        protected override void RemoveItem(int index, object item)
        {
            base.RemoveItem(index, item);
            manager.OnItemRemovedFromList(item);
        }
    }

    private OnItemAddedToList(object o)    
    {
    }

    private OnItemRemovedFromList(object o)    
    {
    }
}

I'm not sure if this is the right way to do it though and I'd like to see if there are any better alternatives.

Answer 3

Personally I'd implement IList<T>, in a class that has Added, Removed and Replaced events/delegates. The class would have a private instance member of type List<T> that all implemented calls would delegate to, as well as raising the events.

You could additionally have OnBefore..., OnAfter if you prefer, allowing you to "cancel" the addition/removal of elements.

This is typically how it's done, but like mookid said, there are probably existing libraries out there that do a similar thing. The DataTable class implements a similar concept with the DataRow class, including addition, removal and updating.

You could combine the concepts so that items added to the collection can raise OnChanged events that "bubble" up to the collection and can be used to re-raised a ItemChanged event on the collection.

Answer 4

You could also consider using the System.Collections.ObjectModel.ObservableCollection<T> class, which provides this for you in the form of the CollectionChanged event, which gives you the info about what's changed.

Answer 5

If you are writing custom collections anyway you can implement the INotifyCollectionChanged or the INotifyPropertyChanged interfaces. They add events that you can subscribe to that notifies the listener when the collections data is changed somehow.
Doing this you can subscribe to the events in code outside your collection.

Alternatively you can use the ObservableCollection<T> class which implements both these interfaces. Both the INotifyCollectionChanged interface the the ObservableCollection<T> are only available in .Net Framework 3.0 and above.

On .Net Framework 2.0 you can use the IBindingList interface to get the same functionality, but it is more complex to implement than the INotifyCollectionChanged interface in 3.0

Answer 6

In 2.0 and above, there is BindingList<T> which has all the necessary hooks for an observable collection. There is also (as already mentioned) now an ObservableCollection<T> class, which is very similar.

Deriving a new collection from Collection<T> is also pretty reasonable in many circumstances. But don't derive from List<T>, as this has no (useful) virtual methods.