Guideline 7. Design Messengers when you don't know the behavior

In Guideline 4, I encourage you to think of objects of bundles of services, not bundles of data. In Guideline 6, however, I point out that in practice some objects are bundles of data anyway. Such objects, which I call messengers, show up at the state end of the state-behavior spectrum shown in Figure 5-1. In this guideline, I explain why it sometimes makes sense to disregard Guideline 4 and create messengers.

A messenger is an object that allows you to package and send data. Often data is passed to a messenger's constructor, and the messenger is sent along its way. Recipients of the messenger access the data via accessor methods, which in Java usually take the form get. Messengers are usually short-lived objects. Once a recipient retrieves the information contained in a messenger, it usually kills the messenger (even if the news is good).

In general, you should move code to data as described in Guideline 4. Most of your object designs should be service-oriented objects, as described in Guideline 6. But on occasion, you may find yourself with some data that you don't know what to do with. Sometimes you know some information, but you don't know what behavior that information implies. You can't move the code to the data, because even though you know the data, you don't know what the code should do. In such cases, you can encapsulate the data inside a messenger object, and send the messenger to some recipient that does know the behavior implied by the data. The recipient extracts the data from the messenger and takes appropriate action.