Екі жіберу: Екі нысан түріне қарай функцияны таңдау механизмі

In software engineering, double dispatch is a special form of multiple dispatch, and a mechanism that dispatches a function call to different concrete functions depending on the runtime types of two objects involved in the call. In most object oriented systems, the concrete function that is called from a function call in the code depends on the dynamic type of a single object and therefore they are known as single dispatch calls, or simply virtual function calls. Dan Ingalls first described how to use double dispatching in Smalltalk, calling it multiple polymorphism.

The general problem addressed is how to dispatch a message to different methods depending not only on the receiver but also on the arguments. To that end, systems like CLOS implement multiple dispatch. Double dispatch is another solution that gradually reduces the polymorphism on systems that do not support multiple dispatch.

Double dispatch is useful in situations where the choice of computation depends on the runtime types of its arguments. For example, a programmer could use double dispatch in the following situations:
Sorting a mixed set of objects: algorithms require that a list of objects be sorted into some canonical order. Deciding if one element comes before another element requires knowledge of both types and possibly some subset of the fields. Adaptive collision algorithms usually require that collisions between different objects be handled in different ways. A typical example is in a game environment where the collision between a spaceship and an asteroid is computed differently from the collision between a spaceship and a spacestation. Painting algorithms that require the intersection points of overlapping sprites to be rendered in a different manner. Personnel management systems may dispatch different types of jobs to different personnel. A schedule algorithm that is given a person object typed as an accountant and a job object typed as engineering rejects the scheduling of that person for that job. Event handling systems that use both the event type and the type of the receptor object in order to call the correct event handling routine. Lock and key systems where there are many types of locks and many types of keys and every type of key opens multiple types of locks. Not only do you need to know the types of the objects involved, but the subset of "information about a particular key that are relevant to seeing if a particular key opens a particular lock" is different between different lock types.

The common idiom, as in the examples presented above, is that the selection of the appropriate algorithm is based on the call's argument types at runtime. The call is therefore subject to all the usual additional performance costs that are associated with dynamic resolution of calls, usually more than in a language supporting only single method dispatch. In C++, for example, a dynamic function call is usually resolved by a single offset calculation which is possible because the compiler knows the location of the function in the object's method table and so can statically calculate the offset. 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).

In C#, when calling an instance method accepting an argument, multiple dispatch can be achieved without employing the visitor pattern. This is done by using traditional polymorphism while also casting the argument to dynamic. The run time binder will choose the appropriate method overload at run time. This decision will take into consideration the run time type of the object instance (polymorphism) as well as the run time type of the argument.

The Eiffel programming language can bring the concept of agents to bear on the double dispatch problem. The example below applies the agent language construct to the double dispatch problem. Consider a problem domain with various forms of SHAPE and of drawing SURFACE upon which to draw a SHAPE. Both SHAPE and SURFACE know about a function called `draw' in themselves, but not in each other. We want objects of the two types to co variantly interact with each other in a double dispatch using a visitor pattern. The challenge is to get a polymorphic SURFACE to draw a polymorphic SHAPE on itself.

Before looking at SHAPE or SURFACE, we need to examine the high level decoupled use of our double dispatch.

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 also have specific signatures and possible results (in the case of queries), making them ideal static type checking vehicles without giving up specific object details. 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. The use and mechanics of agents ensure this. One possible downside of the use of agents is that an agent is computationally more expensive than its direct call counterpart. With this in mind, one ought never to presume the use of agents in the double dispatch and their application in visitor patterns. 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.