Ok, the subject line sucks, but I couldn't think of any way to explain it both clearly and concisely.

I am designing a system that will have a main program and a bunch of modules that will be in dlls. Each dll will include an object that will implement a certain interface, such that the main program can instantiate an instance of the object via the interface. Much of that is boilerplate. The question comes in because there are two different things (Moves and Divisions) that can happen on the main form that each module may or may not want to deal with.

My first thought was that the interface could include a Moves method and a Divisions method. Those modules that don't actually want to do anything can leave the methods empty. The main app would then go through the list of objects loaded from the dlls and call Moves or Divisions on each one in turn. As you can see, this is almost exactly how events work, except that in my case, the methods will be called on a class even if the class doesn't actually DO anything in the method.

Therefore, it occured to me that events would actually handle this a bit better. After all, the main program could simple raise the events, and the modules could handle the event or not, as they chose. This would be somewhat more efficient than the other design. However, I see no way to add a handler in the dll without passing it the object that will raise the event, which would be the main form in the main program. This would be really bad, because it hands each dll the keys to the kingdom.

To get around that, I thought I might make a class that wrapped the events, and had methods that raised the events. The main form would have an instance of this class, and use it to raise these custom events rather than raising them directly. The class could then be passed to the dll without giving the dll any direct access to the main form.

Does that sound reasonable? Is there a third option?