[1] The general problem addressed is how to dispatch a message to different methods depending not only on the receiver but also on the arguments.
In a language supporting double dispatch, this is slightly more costly, because the compiler must generate code to calculate the method's offset in the method table at runtime, thereby increasing the overall instruction path length (by an amount that is likely to be no more than the total number of calls to the function, which may not be very significant).
However, the following code does not work as desired: The desired behaviour is to bind these calls to the function that takes theApolloSpacecraft as its argument, as that is the instantiated type of the variable, meaning the expected output would be Asteroid hit an ApolloSpacecraft and ExplodingAsteroid hit an ApolloSpacecraft.
The problem described above can be resolved by simulating double dispatch, for example by using a visitor pattern.
The key is that theSpaceShipReference.CollideWith(theAsteroidReference); does the following at run time: In C#, when calling an instance method accepting an argument, multiple dispatch can be achieved without employing the visitor pattern.
Instead, the code relies on run-time polymorphism and the mechanics of agents to achieve a highly flexible co-variant relationship between these two deferred classes and their descendants.
The visitor pattern works by way of a visitor object visiting the elements of a data structure (e.g. list, tree and so on) polymorphically, applying some action (call or agent) against the polymorphic element objects in the visited target structure.
This level of indirection and decoupling is simply not achievable in other common languages like C, C++ and Java except through either some form of reflection or feature overloading with signature matching.
This is a distinct advantage of Eiffel agents over the single inheritance, dynamic and polymorphic binding of other languages.
Again, the agents provide the indirection and class agnostics required to make the co-variant relationship with SHAPE as decoupled as possible.
Additionally, please take note of the fact that SHAPE only provides `drawing_data_agent' as a fully exported feature to any client.
What we want is a double-dispatch method for handling encounters (e.g. possible collisions) between two co-variant objects in our make-believe universe.
Finally, note that encounter calls to `print' do not include specific information about possible descendant classes of SPACE_OBJECT!
The fact that the output of the `print' makes sense to us, as human beings, based on what we know or imagine about Star ships, space stations and asteroids is merely logical planning or coincidence.
With regards to double-dispatch, Eiffel allows the designer and programmer to further remove a level of direct object-to-object knowledge by decoupling class routines from their classes by way of making them agents and then passing those agents instead of making direct object feature calls.
The agents are fully polymorphic so that the resulting code has only the specific knowledge required to get its local job done.
Otherwise, there is no maintenance burden added by having specific internal class feature knowledge spread around many co-variant objects.
If one can clearly see a design limit as to the domain of class types that will be involved in the co-variant interactions, then a direct call is the more efficient solution in terms of computational expense.
However, if the class domain of participating types is expected to grow or differ substantially, then agents present an excellent solution to lessening the maintenance burden in the double-dispatch pattern.