Hand Off is a pattern described in DesignPatternsForDistributedObjects. This page is presently a discussion page, and will become more formalised over time.
Intent
Decouple the main thread of execution from access to remote services so that communications delay is reduced.
Description
A thread is performing some operation. At some stage, it has to do some other work which may take a long time, such as invoke a method on a remote object. The thread does not want to be delayed, and:
This seems more like a multi-threading strategy rather than a distributed objects strategy: When you want to do something that will take a long time, but you don't need the result right away (or at all), queue the work to another thread (in the same address space!) to work off at its leisure.
In fact, to avoid the cost of the communications delay (described in your Intent section), don't your Known Uses always queue work to local threads?
-- JeffGrigg
When I read the name and Intent, I thought you were going to suggest passing objects by value across the network when they make a transaction from a state of interacting primarily with local objects to a state of interacting primarily with remote objects. Thus, moving the object itself from one system to the other would minimize round-trips / communications delays.
Example:
A JavaSwing client builds an Order containing the things the user wants to buy. The GUI interacts heavily with the Order object and its lines. Now the user presses the "BUY IT NOW" button, and the Order must interact heavily with server objects to check inventory, do billing, and all the other server-type-things that need doing. It may be best to move the Order data to the server (pass by data instead of pass by reference), and reconstitute it with server objects before doing all the server work.
-- JeffGrigg
Yes, I agree that the pattern's name is misleading. That's why I've called this page HandOff (a NounPhrasePatternName?). I always intended that the work was done in the same process, but in a different thread. This is applicable when you are trying to avoid even one communication delay. The order object pattern is appropriate when one communication delay is acceptable and you're trying to avoid lots more.
Your comment on multi-threading is right on the mark DesignPatternsForDistributedObjects overlap with ConcurrentProgrammingPatterns.
-- JohnFarrell