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

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.

Answer 2

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.