... LocalConceptPresence has led to multiple object instances, each in its own computing context, that represent a single analysis concept. Each computing context has its own interface to this single "logical" object. ---- '''We want to avoid unnecessary coordination''' '''between multiple instances of one concept.''' Many method invocations will require coordination among the objects, either at the business rule level or at the level of object state coordination, or both. We want to be able to distinguish between methods that require coordination and those that don't. You could factor the shared state and behavior into a separate object (see RelationshipObject). However, what is local and what is shared may change with business rules, and you want to minimize the code changes that must be made to reflect such changes in methods and data structures. Also, OccamsRazor suggests against creating an object just for this purpose. ''Therefore:'' '''For methods that require no coordination''' '''between objects, just execute the method''' '''locally.''' In C++, you can declare such methods to be ''const'' member functions, documenting that they do not change the state of the object, so no state coordination between instances is necessary. Other methods can coordinate using SymmetricalReference. ---- This provides an efficient alternative to RemoteProxy for objects where a significant fraction of method calls can execute locally. Factoring out this pattern separate from SymmetricalReference and LocalConceptPresence makes it possible to combine the patterns in interesting ways that capture several other RPC approaches. The original HalfObjectPlusProtocol is one archetypical combination of the patterns SymmetricalReference, LocalConceptPresence and AutonomousCopy.