Communication between objects in C# .NET

gamma_strahler · 2007-04-06T18:43:23+00:00

Hi, i´m currently writing a 3D editor for my FPS shooter, using C# .NET. Now i came across a situation which seems to be difficult to solve. I want to change the status text of the status bar, which is inside my mdi form. But the problem is, the object that needs to change the status text, has no access to the status bar instance. Is there a smart solution to communicate between objects in C# .NET? I could just …

Quote:
Original post by gamma_strahler
Quote:
Original post by TheUnbeliever
A good way of handling events is to use a delegate, in C#.

But what is the advantage of using delegate event handlers? I have read some tutorials about them, but it seems to me that i could also implement this strategy by just adding a class method?

In my class, delegates don´t help me lot i think, since the panel which raises the event must explicitly call the delegate of the parent´s form. This is just as if i would call a normal procedure

It depends on what you mean by 'adding a class method'.

Delegates let you easily have listeners register with a class and then be notified of updates. Here's a slightly manufactured example of how you might handle your situation.

class TemperatureMonitor{    public readonly string ID;    public readonly int Temperature;    public class OverheatEventInfo    {        public readonly DateTime At;        public readonly int Temperature;                public OverheatEventInfo(DateTime Time, int Temperature)        {            At = Time;            this.Temperature = Temperature;        }    }    /* OverheatHandler essentially specifies the signature of the functions      * which can subscribe to our event.     *     * The OnOverheat delegate is what the listeners actually subscribe to.     * The usage of the 'event' keyword means that whilst others can subscribe     * to our event, only we can actually fire the event. Without it, anyone     * can subscribe - but also, anyone can fire the event. This might be     * desirable sometimes, but not here.     */    public delegate void OverheatHandler(TemperatureMonitor Sender, OverheatEventInfo Data);    public event OverheatHandler OnOverheat;    public TemperatureMonitor(string ID)    {        this.ID = ID;    }    // MonitorSomething could obviously itself be an event handler    void MonitorSomething(int Temperature)    {        this.Temperature = Temperature;        if (Temperature > 70)            if (OnOverheat != null) // Just check we have listeners first                OnOverheat(this, new OverheatEventInfo(DateTime.Now, Temperature));    }}class EmailDispatch{    // ... Implementation largely doesn't matter    /* Of course - we would handle more than just the events from the     * TemperatureMonitor (and we would probably be passed a list of things to     * monitor, too - this is for pedagogical purposes only).     */    public EmailDispatch(TemperatureMonitor ServerTemperature)    {        ServerTemperature.OnOverheat += new ServerTemperature.OverheatHandler(AlertSysAdmin);    }    public IgnoreMonitor(TemperatureMonitor Monitor)    {        /* You unsubscribe the method, not the instance of the delegate         */        Monitor.OnOverheat -= new ServerTemperature.OverheatHandler(AlertSysAdmin);    }    public AlertSysAdmin(TemperatureMonitor Sender, TemperatureMonitor.OverheatEventInfo Data)    {        // ... Send an email warning the sysadmins    }}class Logger{    // Again, this is highly simplified    public Logger(TemperatureMonitor ServerTemperature)    {    }    public WriteEvent(string EventData)    {        // ...    }    public ServerOverheat(TemperatureMonitor Sender, TemperatureMonitor.OverheatEventInfo Data)    {        /* Note - the subscribers are free to make of the event what they will.         * This means that the publisher only needs to worry about what happened         * rather than what it should do about it (because, inherently - it         * shouldn't do anything about it because its job is something         * different). This decreases coupling and increases the semantic         * meaning of the different objects. TemperatureMonitor just monitors         * the temperature and publishes an event if it's too high - the          * listening objects don't have to monitor the temperature themselves         * (which would also mean some repetitive code - which is normally a         * bad thing, albeit one which is sometimes a necessary evil).         */        WriteEvent(Sender.ID +                   " warned of overheat (" +                   Data.Temperature.ToString() +                    " degrees) at " +                    Data.At.ToString());    }}/* ... Ad infinitum - the TemperatureMonitor doesn't care about what happens to * the data or how it's being used; the listeners (EmailDispatch and Logger) * don't need to know how TemperatureMonitor is implemented) */

So, if you've read the comments, you'll see that it's not a case of the panel raising the event calling a delegate of the parent's form (which, you're right, would be only a very little better). It's a case of that panel having a delegate which is then subscribed to by the parent form (or whatever updates the status bar) and anything else that needs to know about it.

In short, the benefits of a delegate:
1. Can have a one-to-many or many-to-many relationship of
publishers-to-listeners without having to change the implementation of the publisher.
2. Increases decoupling because neither the implementation of the publisher nor of the subscribers depends on the other.
3. A delegate can be passed around, so a subscriber can be notified of events without even having to know about the publisher itself.
4. It's pretty much an implementation of the observer pattern (as I understand), so you can feel warm and fuzzy about using design patterns.

[Edited by - TheUnbeliever on April 7, 2007 9:08:17 AM]

Topic Locked