Chapter 1 of API Design
by Bill Venners
Part 17 of 21
[an error occurred while processing this directive]
Guideline 5. Use messengers to transmit
In Guideline 2, I encourage
you to think of objects of bundles of services, not bundles of data.
3, 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
3-1. In this guideline, I explain why it sometimes
makes sense to disregard Guideline 2 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 2. Most of your
object designs should be service-oriented objects, as described
3. 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.