has led to multiple
object instances, each in its own computing
context, that represent a single
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,
We want to be able to distinguish between
methods that require coordination and those that
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.
suggests against creating
an object just for this purpose.
For methods that require no coordination
between objects, just execute the method
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
for objects where a significant
fraction of method calls can execute
Factoring out this pattern separate from
makes it possible to combine the patterns in
interesting ways that capture several other RPC
The original HalfObjectPlusProtocol
is one archetypical combination of the