Ok to use DataEventArgs instead of customized event data class?

Question

Is using a generic DataEventArgs class, rather than declaring and using a custom EventArgs inherited class, in an event declaration, a violatio

Answer 1

There's little reason not to use a generic EventArgs subclass for non-public events. However, for events that are part of a truly public API, things get a bit trickier due to potential backward compatibility concerns. For a publicly consumed event, creating an event-specific EventArgs subclass would give you flexibility to add members without affect the API consumers.

For an event that is not part of a public API, there would still be a bit of potential rework to be done if the EventArgs subclass was changed for a particular event because the generic subclass was no longer a good fit. However, this should usually be fairly minimal, and the compiler should catch any problems (whether explicit or anonymous handler methods are used). Obviously, there's a trade-off to be made there between the initial development effort and the potential change effort -- fwiw, I use a generic EventArgs for internal events where it's a good fit, and I've rarely needed to change one after initial release.