Module events

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?

Delegates... sort of a hybrid version of your options above. If you have a List (Of your delegate) you could pass it momentarily to your dll objects using a RegisterDelegate method (or what ever name) and it would add it's copy of the delegate method to the list...
From the form, you can then iterate through the list and invoke each of the methods in it. That way you're only tracking and calling the modules that actually have implemented those methods. Might want to think about a Dictionary now that I think about it, and have a means for UnRegistering the methods too (for unloading a module).

Did that make any sense?

-tg

Yeah, that made complete sense. I see no real advantage over my second option, but it is certainly superior to the first option.

Unregistering is not an issue. Each module will be added when the program starts and will not unload while the program is running, though they could be removed after the program has ended.