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