Custom (derived) List

Question

Feel free to load your guns and take aim, but I want to understand why you shouldn't do this.

I have created a custom class designed to replace any instances of List (which I use to update XML objects behind them):

public class ListwAddRemove<T> : List<T> {
    public event EventHandler<ListModifyEventArgs> OnAdd;
    public event EventHandler<ListModifyEventArgs> OnRemove;

    new public void Add(T o) {
        base.Add(o);

        if (OnAdd != null) {
            OnAdd(this, new ListModifyEventArgs(o));
        }
    }

    new public void Remove(T o) {
        base.Remove(o);

        if (OnRemove != null) {
            OnRemove(this, new ListModifyEventArgs(o));
        }
    }
}

The idea is whenever I add or remove an item from this list my bound events will fire and I can deal with the XML behind automatically.

This works like a charm, so far so good.

But how do I handle a conversion between object.ToList() and my derived version?

A lot of people are saying you should derive from Collection instead... why?

Have you heard about ObservableCollection ? http://msdn.microsoft.com/en-au/library/ms668604(v=vs.110).aspx and http://stackoverflow.com/questions/3167752/is-there-a-way-to-convert-an-observable-collection-to-a-list — aybe, Dec 10 '13 at 11:49
Using the `new` modifier to hide members from the base class is never a good idea. If you really feel like deriving from `List<>`, give your methods some new names, such as `AddAndRaiseEvent` or similar. However, `List<>` class is not really designed for this use. There are other classes that offer more `virtual` members meant to be helpful when inheriting them. — Jeppe Stig Nielsen, Dec 10 '13 at 12:43
@user1830285 ObservableCollection is still available in .Net 3.5 and can be used with Windows Forms, it's just a Collection that implements `INotifyCollectionChanged` and `INotifyPropertyChanged` interfaces. See http://stackoverflow.com/questions/4279185/what-is-the-use-of-observablecollection-in-net for more info. — user692942, Dec 10 '13 at 13:29

Joe · Accepted Answer · 2013-12-10T13:09:34.110

You should derive from Collection<T> because it's designed to allow you to override InsertItem, and RemoveItem to add custom behavior such as what you're doing (also SetItem, to add custom behavior when changing an existing item).

It can therefore be used as an IList<T>, and any insertion/removal will automatically use the customisation.

In your case, anyone who casts to IList<T> or the base class List<T> will bypass your custom Add/Remove functionality.

Collection<T> also provides a constructor to wrap an existing list. You can expose this from your derived class to wrap a list generated by Enumerable<T>.ToList().

UPDATE

Whats the syntax to expose the constructor please?

Very simple:

public class ListwAddRemove<T> : Collection<T>
{
    public ListwAddRemove<T>()
    {
    }

    public ListwAddRemove<T>(IList<T> list) : base(list)
    {
    }

    ... implementation of overrides for InsertItem, SetItem, RemoveItem ...
}

Then use it as follows:

IList<SomeType> list = ....ToList();
ListwAddRemove<SomeType> myList = new ListwAddRemove<SomeType>(list);

Anyone who casts to the `IList` interface will lose the new functionality, but so will anyone who casts to the base class `List` (as in MartinStettner's answer). — Jeppe Stig Nielsen, Dec 10 '13 at 12:39
"You can expose this from your derived class to wrap a list generated by"... Whats the syntax to expose the constructor please? I'm liking this implementation — user1830285, Dec 10 '13 at 12:53
Its ok got it:public ListwAddRemove(List incomingList) : base(incomingList) { } — user1830285, Dec 10 '13 at 13:06

score 2 · Answer 2 · answered Dec 10 '13 at 11:56

For one,

void DoSomeAddingToList(List<int> list) {
  list.Add(1);
}

var list = new ListwAddRemove<int>();
DoSomeAddingToList(list);

will not trigger the events. That might lead to strange effect, especially if you're not the only one using the class.

List<T> defines a very specific behaviour for Add and Remove (since it's a concrete class), and users might rely on exactly this behaviour.

I think this is generally true for using a new modifier, so this language feature should be used with caution, especially on public methods.

As others have mentioned, implementing IList<T> (using delegation/aggregation) is probably the better choice.

Custom (derived) List

2 Answers2