... 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.