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).

question from:https://stackoverflow.com/questions/2020381/when-to-use-callbacks-instead-of-events-in-c

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.