Fundamental differences between a List<Action> vs Action

Question

Is there any fundamental difference between to using an action and a list of actions? Seeing that action is a delegate and therefore is a list itself. For instance:

List<Action> technicallyRedundant = new List<Action>();
technicallyRedundant.Add(() => { Console.WriteLine("Action 1"); });
technicallyRedundant.Add(() => { Console.WriteLine("Action 2"); });

Is this architecture more readable? Which would be recommended for use when exposing for an external library?

Action act = null;
act += () => { Console.WriteLine("Action 1"); }
act += () => { Console.WriteLine("Action 2"); }

Answer 1

Yes, there is a fundamental difference between the two: type safety.

Whilst GetInvocationList can indeed be called on act in your example, it doesn't return a list, it returns an array of Delegate. As a result, the slower DynamicInvoke must be used to run it and the wrong parameters can easily be passed to it, as demonstrated by the following compilable code:

Action act = null;
act += () => { Console.WriteLine("Action 1"); };
act += () => { Console.WriteLine("Action 2"); };
foreach (var action in act.GetInvocationList())
{
    action.DynamicInvoke("1");
}

Run this and it'll throw a TargetParameterCountException.

Whereas with List<Action>, we have a strongly typed list. In any iteration of it, we'd be dealing with Action, rather than Delegate. Thus Invoke() can be used, which knows the parameter requirements.

Answer 2

The main difference is internal. Delegate is a linked list; List uses an array internally. For a public API, you should not use either. List is not supposed to be exposed in properties, and a public delegate is usually an event. Perhaps you want a delegate parameter instead.

As the other poster said, List is strongly typed, but an event can also be strongly typed. The delegate would then be hidden in generated code.

Check out the .net Framework Design Guidelines for public collection property and event/delegate guidelines.