Callback injection

Question

I have a service that needs to make a callback. Basically, it is an event that is expected to be handled in exactly one place, and that is too important to be optional.

The obvious approach seems to be to inject an Action. In the context of dependency injection, is it considered good (or acceptable) practice to do so?

I'm also eager to hear why (not), or what alternatives you would consider.

One particular problem that comes to mind is in the following scenario:

• Parent's constructor takes an IChild.
• Child's constructor takes an Action, the callback.
• Parent has the method that is to receive the callback.
• To instantiate the Child, we need the Parent's method, and thus the Parent instance. But to create that, we first need the Child instance. Problem.

One solution I can think of is to inject an IChildFactory instead. Parent's constructor can then use that factory to create the Child instance. At this point, Parent exists, and thus it can pass its callback method to the factory.

This solution seems to get the job done, but I'm curious about alternatives.

Answer 1

Why did I not think of this before?

We can simply inject into Parent's constructor a Func<Parent, Child>, a function that takes the Parent as a parameter and returns the [new] Child. (Alternatively, the function could accept the callback method instead of the entire parent - the idea is the same.)

In Parent's constructor, Parent exists, so it can pass [part of] itself to the function that creates Child. Then, it can assign the created Child to its read-only property.

Answer 2

Yes, injecting a callback is absolutely acceptable. I would usually prefer to do it this way.

An alternative, which you've already pointed out, is to define an event on the service object and use a factory to create it - making sure that it's the only way to create it and then have the factory handle the event, or delegate it further (which brings us back to square one).^*

The specific parent/child example may have other solutions, depending on your context. For example, you could create the parent, and pass it to the child constructor, which could insert itself as the parent's child.

_{* Clarification: My suggestion was to either inject a callback or use a factory that registers an event handler in the regular way. In this case, to enforce your requirement that the event must be handled, only the factory should create service objects. Then no-one can create a service object without registering an event handler.}

_{You may want to use a factory even with the injected callback for other reasons (e.g. to make sure the correct callback is provided). Also you may have multiple such factories. Those are separate considerations.}

Answer 3

As per EmersonCardoso's comment, we might inject the Parent into the Child via property injection:

• Child is injected into Parent, by constructor injection.
• In Parent's constructor, it sets itself on one of Child's properties.

This helps deal with the cyclic nature of the dependencies. The solution is much like having a public event property, except for only a single handler.

Disadvantages might be:

• The dependency has become (compile-time) optional.
• Child has become stateful. Stateless services are a good practice anyway, and even more so in DDD, for example.
• Child has become externally mutable. Even if statefulness is deemed acceptable, external mutability is something I would avoid.