In
ValueObjectHypotheses, someone asks:
Can anybody think of a good reason for holding a reference to a reference object within a value object?
Here's my example:
I define an interface:
MemoryAddress. This is an index into a Memory. Users of the
MemoryAddress interface see objects as values.
However, life isn't so simple in the implementation of the object. In my
application, a memory address isn't simply a number. It is defined by a
section plus an offset. A locator tool can take abstract sections and
locate them in physical memory. The physical memory in which a section
is located effects its performance characteristics (e.g. is the memory
cacheable?). My application is a tool for performance analysis and
optimization: sections and memories are definitely reference objects
that are manipulated.
But the part of my code that emulates the execution of code, and accesses
to data only handles addresses. The
MemoryAddress interface gives the
object a
ValueInterface, even though the object the implements that
interface might be a
ReferenceObject. The fact that manipulating
sections changes the physical address is irrelevant because
the identity is unchanged, and the users of the interface never see
the actual physical address. The Interface defines equivalence classes
over the object's state.
As a user of the
ShlaerMellorMethod, I see the separation of the
views in terms of different subject matter domains. In one domain,
the address is a value; in the other it's an object.
--
DaveWhipp
"Can anybody think of a good reason for holding a reference to a reference object within a value object?"
How about a
capability. A capability encapsulates permissions to perform actions on a
ReferenceObject, and so holds a reference to the target object and a bit-set of operations that the owner of the capability is allowed to invoke. A capability is a
ValueObject because the owner of a capability must not be able to change the permissions that they have been given, but may create more restrictive capabilities to be handed over to other parties.
--
NatPryce
CategoryInterface