Let's say we have an object that is going to consume some object but, in the process, will be affected by that object or, perhaps, the environmental context of the action.
To bring that closer to home, consider eating. The eater consumes the eatie. The eatie, by being consumed, can cause all sorts of possible affect to the eater: indigestion, increased energy, nourishment, or even death by poison...
So the eater does its eating thing but then the eatie does its decomposing via digestion.
Here's a simple example.
/// define our delegate
{
PreyDigestion(
alMeals.Add(PreyDigestion);
}
Digested DigMeal = (Digested)alMeals[iMeal];
DigMeal(predator);
/// class Mammal
predator.Nourish();
/// class fish
/// class Algae
predator.Die();
Now, If the bear eats the fish, she will be nourashed and happy. If the fish eats the algae, he is nourished. If the Bear eats the Algae, she will die of Ciguatera Toxin Poisoning. If the Fish first eats the Algae before the Bear east the fish, the Bear will die of poisoning just the same.
Using inheritence and delegates passed as parameters, everything an organism consumes becomes part of them and, should they be eaten, their consumer will have to digest their meal as well.
What did we learn? Bears shouldn't eat algae and should avoid large quantities of fish that eat algae. Stick to Salmon and Tuna.
As opposed to the service class having to expose a method or support an interface that the client can call, the client can expect a delegate as a parameter. That parameter might be something completely separate from the service class. Perhaps a transponder was attached to the fish and now the transponder is in the bear...
See and step through the attached example if you want to watch it in action.