Summary
In a recent java.net article, Peter Becker examines notions of object identity in Java, including identity in terms of memory location, business identity, and database identity, and suggests that developers define equals() in a way that avoids references to mutable fields.
Advertisement
Notions of Java object identity are well defined in the JDK docs, and most developers understand the difference between == and equals(). However, identity is a more complex issue in real-world applications, as Peter Becker's recent java.net article, You Are What You Is: Defining Object Identity, observes. He distinguish between notions of identity in the following contexts:
Keeping identity when your program stops
What happens with objects that are needed after you shut down a program and restart it? Objects usually get serialized and then get deserialized when they are needed again...
Having objects represent external data
Objects can come from external sources, such as a relational database. The structures on which these objects are based often define their own identities such as using primary keys to identify rows in a table.
Having identifiers in the business world
What happens if ... the business side already has a strong notion of how to identify entities? Order numbers, passport IDs, and social security numbers are examples of this...
Becker proposes that you:
Make sure that the way a program understands the identity of objects is the same as the notion of identity that comes out of the business context.
He then proceeds to distinguish between value objects and state objects in defining identity, and illustrates implementing equals in a way that relies on a business notion identity. He also shows why equals() should not rely on mutable fields in the case of value objects:
[It] can be quite useful to completely distinguish state objects and value objects. A state object is an object that stores mutable state and is identified through reference equality, very much a standard Java object with getters and setters. A value object is always immutable and is identified through value equality. In Java that means overriding equals() and using only private members with no setters.
What do you think of Becker's notions of defining identity? Especially in a database application, what are your preferred ways of defining object identity?
i hinted at it in the original thread, but for me, data is inherently transient, thus equality will always be a simpler solution. database identity, imo, is an unnecessary layer of complication since data exists as an abstraction above the original store. i think in the 4 or so years of web development work, the famous identity vs. equality bug has never creeped into my code or the code of people i've worked with.
Very Interesting discussion... Kevlin Henney on http://www.curbralan.com/ has discussed the need of precise design on Value Object on more documents. Very important, about me, is the paper "Valued Idioms: Patterns for Value-Based Programming" in which design of Value Object derive from a discussion about main features of concept of Object: identity, state, behaviour...
Previous Topic
