When to use callbacks instead of events in c#?

Question

Forgive me if this a stupid question, I admit I haven't thought about it much.

But when would you favour using a callback (i.e, passing in a Func or Action), as opposed to exposing and using an event?

UPDATE

What motivated this question was the following problem:

I have a ThingsHandler class, which can be associated with a ThingEditor. The ThingsHandler handles a list of Things, knows their order, which one is 'current', when new ones are added or deleted etc.

The ThingEditors can just modify a single thing.

The ThingsHandler needs to alert the ThingEditor when the user selects a new Thing to edit, and the ThingEditor needs to alert the ThingsHandler when the user says 'done'.

What bothers me is having these two classes holding references to each other - though I guess that's inevitable - or binding to events in both directions. I wondered if using a callback in one direction was 'cleaner'.

I suspect there is a design pattern for this, and humbly apologise for my ignorance (and sloth).

Answer 1

I use callbacks in a few cases where I know it will only ever fire once, and the callback is specific to a single method call (rather than to an object instance) - for example, as the return part of an async method.

This is particularly true of static utility methods (since you don't have an instance, and static events are deadly when used carelessly, and to be avoided), but of course the other option is to create a class instance with an event instead.

Answer 2

Callbacks are good when one object wishes to receive a single notification (e.g. an Async data read runs and then calls you with the result).

Events are good for recurring notifications that can be received by an arbitrary number of listeners.

Answer 3

In terms of OO design and class coupling there isn't great deal of difference between a callback interface and an event.

However, I prefer events where they are things the class needs to "shout about" to whoever is interested in listening (usually multiple things) and callbacks where a specific class has requested an async operation.

Whatever you use, use them consistently across the codebase!

Answer 4

I would use Func or Action when I am going to call the function once or use a Lambda expression.

Events can be registered more than once which sometimes is ideal. With a callback, one has to implement a registration system for the callbacks if you want multiple.

Answer 5

One example is when the callback should return something. E.g. (stupid example):

public int Sum(Func<int> callbackA, Func<int> callbackB) {
    return callbackA() + callbackB();
}

public void UseSum() {
    return sum(() => 10, () => 20);
}

Answer 6

Generally, I use a callback if it is required, whereas an event is used when it should be optional. Don't expose an event if you're expecting there to always be something listening.

Consider the following:

public class MyClass_Event
{
    public event EventHandler MakeMeDoWork;

    public void DoWork()
    {
        if (MakeMeDoWork == null)
            throw new Exception("Set the event MakeMeDoWork before calling this method.");
        MakeMeDoWork(this, EventArgs.Empty);
    }
}

vurses:

public class MyClass_Callback
{
    public void DoWork(EventHandler callback)
    {
        if (callback == null)
            throw new ArgumentException("Set the callback.", "callback"); // better design
        callback(this, EventArgs.Empty);
    }
}

The code is almost the same as the callback can be passed as null, but at least the exception thrown can be more relevant.

Answer 7

Though the other answers thus far seem reasonable, I would take a more philosophical tack.

A class is a mechanism that models a particular kind of thing in a particular domain. It is very easy when writing the internal details of a class to conflate the implementation details of the mechanism with the semantics being modeled. A brief example of what I mean:

class Giraffe : Mammal, IDisposable
{
    public override void Eat(Food f) { ... }
    public void Dispose() { ... }
}

Notice how we've conflated the real-world thing being modeled (a giraffe is a kind of mammal, a giraffe eats food) with the details of the implementation (an instance of Giraffe is an object which can be disposed of with the "using" statement). I guarantee that if you go to the zoo, you will never see a giraffe being disposed of with the using statement. We've mixed up the levels here, which is unfortunate.

I try to use events (and properties) as part of the semantic model and use callback methods (and fields) as part of the mechanism. I would make GaveBirth an event of Giraffe, since that is part of the model of real-world giraffe behaviour we're attempting to capture. If I had some mechanism, like, say I wanted to implement an inorder-walk tree traversal algorithm that walked the family tree of giraffes and called a method back on every one, then I'd say that this was clearly a mechanism and not part of the model, and make it a callback rather than try to shoehorn that into the event model.