Question

The IDesign coding standard states “Do not provide public event member variables. Use event accessors instead.”

I appreciate that there are situations where event accessors are useful (I think that Control uses a dictionary to only store events that are assigned to save memory). But what is the point of mandating that this boilerplate code always exists?

Edit: explicitly

public event EventHandler EventName;

vs.

public event EventHandler EventName { add { ... } remove { ... } }

[see IDesign Coding Standard – Coding Standards – 42]

Answer 1

Delegate fields are not events – they are just delegate fields. They can be (very incorrectly) inspected, nulled and invoked by external callers, whin is contrary to the design of events (which can only be handles by the declaring class, typically).

The encapsulation allows indirection, validation, etc; all desirable. And the cost is minimal. It would not be normal for this to impact your code’s performance.

It also allows them to be used on interfaces; fields cannot be declared on interfaces.

---

Edit:

The question is a little unclear, but if the question is simply field-like events vs explicit add/remove with a delegate backer… Then that is stupid. Don’t add unnecessary code. Field like events would be preferred, unless there are enough events to warrant an EventHandlerList implementation.

In particular, the 4.0 compiler does the thread-safety very sensibly now (this was not the case historically).