Data Objects Dont Usually Have Functional Methods Interfaces Give You the Data Objects

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 objects identity isnt important. Two distinct data objects are equal if the data they encapsulate is equal. Theyre used to group related pieces of information together in order to pass them over the wire more easily and in a more comprehensible form.

7.2.1 Data Objects Dont Usually Have Functional Methods

Data objects dont usually have many functional methods descriptive methods are fine; theyre 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. [ 10] But a careful look at the first option reveals something interesting: the data is versioning independently of the behavior. If youre explicitly managing data independently of behavior, there are two distinct objects involved. [ 10] The author still has a copy of Netscape N avigator 2 Gold. For this reason, most complex distributed applications tend to have a translation layer. That is, they get data objects off the wire and then translate the data objects into other types of objects, which are more useful in the current application. While this level of indirection can seem excessive when youre first building an application, it turns out to be incredibly convenient as soon as the clients and servers start having distinct lifecycles. The general principle is: In a distributed system, you want the things that involve the network to be as stable as possible. Interfaces shouldnt change quickly and should add only new methods. Data objects shouldnt change at all.

7.2.2 Interfaces Give You the Data Objects

The end result of designing the server interfaces is that we also know what the data objects are. That is, while we dont yet know the internal structure of the data objects, we do know their names and the roles they play within the application. Most of the time, the interface design process also makes it pretty easy to guess what the fields should be, and therefore, which methods the data objects need to support. Here, for example, is the complete implementation of Money : package com.ora.rmibook.chapter7.valueobjects; import java.io.; public class Money extends ValueObject { private int _cents; public MoneyInteger cents { thiscents.intValue ; } public Moneyint cents { superdollars + dollars + cents + cents.; _cents = cents; } public int getCents { return _cents; } public void addMoney otherMoney { _cents += otherMoney.getCents ; } public void subtractMoney otherMoney { _cents -= otherMoney.getCents ; } public boolean greaterThanMoney otherMoney { if _cents otherMoney.getCents { return true; } return false; } public boolean equalsObject object { ifobject instanceof Money { return _cents == otherMoney.getCents ; } return false; } } Even though we think were dealing with United States currency, were using only cents, rather than storing both dollars and cents. This is an old trick from financial applications™it makes the object simpler to write without losing any information.

7.3 Accounting for Partial Failure