How to ensure that an event from an interface is actually raised?

Question

There are many questions about events in interfaces. Here are a couple:

• http://stackoverflow.com/questions/471352/raising-events-in-interfaces
• http://stackoverflow.com/questions/1093139/c-events-and-interfaces

As interfaces are used to enforce a contract for implementation, this makes no sense to me, because it doesn't enforce the actual raising of the event. The specific implementation can always have the event, but not raise it anywhere. Consider the following:

public interface INotifyPropertyChanged
{
    event PropertyChangedEventHandler PropertyChanged;
}

public class SomeClass : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    public string SomeProperty
    {
        get { return this.someField; }
        set { this.someField = value; }
    }

    private string someField;
}

The thing above will compile and work, but even if I subscribe to the PropertyChanged event, nothing will happen. What would be a way to enforce that an event is actually raised, and if not, why have events in interfaces in the first place?

Answer 1

The interface contract defines that the event must be implemented, and may be subscribed to. Actually raising it is left up to the concrete implementation. There is no way to enforce that an event is raised. What if the circumstances required to trigger the event never occur?

Answer 2

Another situation in which PropertyChanged will never be raised is the circumstance that the property is never changed! Do you want to be warned about that too?

But seriously, interfaces are for enforcing a contract of supported behaviour - if you want to enforce actual behaviour (ie - IF this happens THEN that happens), use (automated) testing.

Answer 3

Integration tests or unit tests are the only way that I see you could do what you want. You are then making sure in your implementation the behaviour is what you expect.

Answer 4

You misunderstood the concept of an interface: It explicitely declares an object's behaviour, but it does not enforce it in any way. The programmer is still fully responsible for implementing the interface behaviour correctly. This is nothing a compiler could do.

It's the same as with other contracts, when the involved parties just refuse to adhere to its content...

Thomas

Answer 5

Nothing's really enforced in an interface, you can just put empty method stubs in after all (as long as you return something of the correct type).

The best way to ensure things like this are behaving correctly is to have plenty of tests.

One thing you might consider is code contracts, which let you specify conditions which have to be true at certain times, and these are actually enforced. However, AFAIK this doesn't work with events.

Answer 6

The same can be said for methods: the interface doesn't enforce that they do anything useful, they could all just return null/0/void. Similarly, the implementation is free to raise/not raise an eevent whenever it wants.

If you want to ensure that certain behaviors are executed, then implement them as a abstract base class. Make the public methods public and non-virtual, and then have them call virtual protected methods and raise events. This is the template-method pattern, and it lets you have more control over sub-class behavior.

Answer 7

My take is that this provides a means of subscribing to an event when all you have reference to is the interface an object is using. Otherwise you would not be able to subscribe to the event at all. You are correct that it does not guarantee that the event is used.

INotifyPropertyChanged x = new SomeClass();
x.PropertyChanged += MyHandler;  //you get the idea

If the event were not defined on INotifyPropertyChanged you would not be able to add your handler.

Answer 8

why u want to enforce raising events? may be u have an event and never use it except in some situation:

if(exceptionAccured) { logger.LogExceptionsEvent += ....; }