Bad practice: exposing an event in an interface?

Question

Hi,

Is it considered bad practice to expose events in .net interfaces?

I have found very few .net framework interfaces that expose events.

Thanks

Answer 1

I think this is mainly because events can replace the need for interfaces.

Normally, an interface would be used for an event system in languages such as Java for example. In .NET, if you have an event that can be subscribed to with a single method, there is rarely a need for an entire class as well as that method.

I'm sure there could be legitimate situations where interfaces that implement events exist, but I see events as a way to reduce the need for interfaces, not something to necessarily use to compose interfaces.

I definitely wouldn't consider it bad practice though.

Answer 2

I see no problem with it. It's just specifying a contract, and in particular specifying that it fires that type of event.

I personally use it in a few of our internal interfaces, and it's really helped clean up the code. If you don't specify it in the interface, it's going to have to be in the concrete class, and you'll be tied to a particular implementation.

Answer 3

For what it's worth, I don't believe that it's a bad practice at all.

It's certainly not that common, but (I suspect) that's more because there's a lack of need or use of other techniques.

I've used events on interfaces to very good effect.

Note: If you want to expose the interface through COM or WCF then events are probably a poor choice, but that's a minority of cases.

Answer 4

Events in interfaces have some appropriate uses. They provide a way to specify an "outgoing" interface of an object.

For example, IBindingList contains a ListChanged event.

An important design decision is whether to include the event in an ingoing interface along with other methods or to put it in a separate interface. The key factor is how strongly coupled the methods are to that particular event.

Answer 5

Well, there is one interface in particular that is probably one of the most important interfaces in .NET and it exposes one event... INotifyPropertyChanged. :)

I have never seen any recommendation against it from FxCop or the Framework Guidelines and I can't see why there would be. The only thing is if you implement the interface explicitly it becomes a pain in the butt to implement the event as you have to use the explicit add/remove accessors.

Answer 6

It is perfectly logical for an interface to require an event, when the interface actually requires an event!

Answer 7

I don't think it's bad at all! I defined an interface so that I can decouple my main application from a component that I need to frequently update and thus, dynamically instantiate and invoke at runtime. In order to communicate status about what the component does, I defined several events in the interface contract so that the main application knows what to subscribe to and the component publishes exactly what the main application needs.