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.

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