In the last few columns, we studied the rule of ownership. Now we turn our attention to the rule of identity. The rule of identity consists of the following four clauses:
- Every object has unique identity, independent of its state
- All clients accessing the same object can expect uniform behavior
- Identity is independent of location
- The identity of its owner is intrinsic to the identity of an object
Let's take a closer look at each of those clauses.
Unique object identity
Every object has unique identity, independent of its state. That is exactly the rule that Rumbaugh et al. defined in their definitive work Object-Oriented Modeling and Design: "All objects have identity and are distinguishable...by their inherent existence and not by descriptive properties that they may have" (page 22).
Because objects have identity, a program must elect to operate on one as opposed to another. For example, suppose that you define a relational database table that has no unique key. Despite the fact that such a table is not properly normalized or indexed, each row has identity. While it is possible to store the same data in multiple rows, a program such as the one shown below in pseudocode may still uniquely identify a row and even change its content independent of the others.
index = 0
rs.open
while not rs.eof do
rs.field1.value = index
index = index + 1
rs.next
end while
This begs the question: If rows in relational tables already have identity, why index a unique key? The unique key is the mechanism by which we programmatically identify rows. Without an artificial mechanism, we would have no reliable, general way of returning to the same row time and again. We would have no way of relating two tables to record a relationship. We would have no way of taking advantage of a row's intrinsic identity.
Uniform object behavior
All clients accessing the same object can expect uniform behavior from the object. In other words, all clients reference the same object, which has only one state and behaves in only one way. That enables clients to communicate through the shared object; if one client makes a change, the others can see it.
Location independence
Most natural implementations of objects -- including structures, database records, and files -- have identity because they occupy a single location, whether in memory or in storage. True identity, however, transcends location, allowing a single object to exist in many places or in many forms. Take, for example, a database record and a structure that caches the record's data in memory. As representations of the same object, the record and the structure should cooperate to obey the other clauses of the identity rule, including uniform behavior.
We will talk about implementing such cooperation in an upcoming column.
Owner's identity
Finally, the identity of its owner is intrinsic to the identity of an object. This is a by-product of the nontransferable nature of ownership. Once an object is created by or for a particular owner, it cannot be moved to another. It can certainly be copied, but the copy obtains a new and unique identity in the process. We can see evidence of this in hierarchical file systems, such as those used by Windows or the Internet, as illustrated below.
Because the identity of its owner is part of the identity of an object, we can identify an object via its ownership path. For example:
- Windows records the full path to a file in a shortcut
- OLE records the path in a moniker to represent a link
- The Internet uses a URL to uniquely identify an object
In every case, if the file is moved to another location (read owner), the link between owner and object is broken. Semantically speaking, the object that the link identified no longer exists; the new copy is not identical to the original because it has a different owner.
In the next few columns, we will apply the rule of identity to several problems. We will study its implementation in programming languages, evaluate its effect on software design, and explore its possibilities in future solutions.
