problems designing event driven communication

Im struggling a bit with a design issue. Im making a very simple gui system in c#. The code is meant to be reusable so Im looking for the most flexible solution here. The solutions I come up with seem to all have their drawbacks.

For simplicity lets pretend there are three classes: controller, button and the client code. The client code is the code using the gui system. It creates the controller and calls Update() on it. The controller creates a bunch of button instances and calls Update() on them. The buttons draw themselves and check for mouse clicks.

Now the prob开发者_运维知识库lem is how do I get the fact that a button was clicked to the client code?

Option 1: Add GetButton(string name) to the controller class. The client code can then subscribe to the events defined in the button class => GetButton("but").MouseUpEvent += MouseUpHandler; The drawback to this is that this exposes Button.Update() which is, and should only, be used by the controller.

Option 2: Have the controller subscribe to all buttons and the client code subscribe to the controller. The drawback here is more parsing code in the client code as now all events are funneled through the controller, so the client has to check which button sent each event. I prefer to setup the flow of events in the initialization phase like in option 1.

Option 3: Add Subscribe/Unsubscribe methods to the controller for each event (SubscribeMouseUp(string buttonName, GUIDelegate del) etc.) Drawback is the controller api grows quickly.

So right now Im leaning towards option 1, but GetButton returns an interface (IClientButton maybe) that only declares the events, thereby hiding Update() from the client, but Im not sure if this is how interfaces are supposed to be used.

Any insight is appreciated. Bas

---

Presumably this is an issue because Update() is public?

Presuming you've organized your button and controller into the same namespace would using internal protection suit your needs?

---

interface can be used that way, INotifyPropertyChanged is an interace with 1 item which is an event.

what about using RoutedEvents?

---

There's a 4th, maybe more popular option.

Have a dispatcher as a central location to register/unregister with. All event receivers register a callback with the dispatcher. All event generators send their events to the dispatcher.

It keeps the API cleaner and helps to untangle object referencing.

---

In your Controller, add two events - ButtonCreated and ButtonDestroyed.

public event EventHandler<ClientButtonEventArgs> ButtonCreated;
public event EventHandler<ClientButtonEventArgs> ButtonDestroyed;

The ClientButtonEventArgs is simply an EventArgs wrapper around your IClientButton interface.

Have your client code subscribe to both of these events. When the Controller creates a new button, have it fire the ButtonCreated event. The client code can then subscribe to the necessary Button events when it receives the event notification. Similarly, the Controller will fire the ButtonDestroyed event as necessary, allowing the client code to unsubscribe from the Button's events.

In this way, the entire sequence is event-driven. The client code reacts to the creation and destruction of a Button, which it seems like is what you're after.