The classic slogan-level definition of an object is usually written in the form of an equation:
|Object = Data + Behavior|
A data object is an object in which the behavior is de-emphasized, and the object’s identity isn’t important. Two distinct data objects are equal if the data they encapsulate is equal. They’re used to group related pieces of information together in order to pass them over the wire more easily and in a more comprehensible form.
Data objects don’t usually have many functional methods (descriptive methods are fine; they’re how you get the data after all). Every functional method on a data object, every behavior you add, introduces dependencies between the client code and the server code. Suppose, for example, the server needs a new behavior on the data object. Then you need to do one of two things:
Use two different versions of the data object. That is, use the new one in the server and the old one in the client. Be careful with serialization and make sure that the two different versions of the data object have compatible serializations.
Recompile, retest, and redeploy the client application when you change the data object.
In practice, you wind up doing the first. Redeployment is a lot of work, and old versions of client applications tend to persist in strange places anyway. But a careful look at the first option reveals something interesting: the data is versioning independently ...