Appropriate Use of Messengers

In parting, I want to warn you to be suspicious of messengers when they appear in your designs. Challenge their existence. Why? Because in my experience a common problem I encounter in object-oriented design reviews is data-oriented design. When you design the tables of a relational database, you should do data-oriented design. When you design the structure of XML documents, you should do data-oriented design. When you design an object-oriented API, however, you should be doing service-oriented design in which data-oriented objects, such as messengers, are special cases.

A messenger makes sense when you don't know the behavior that's appropriate for some particular piece of data. If you do know the appropriate behavior for a messenger's data, then you should refactor. You should move the appropriate code to the data, which will transform the messenger into a more service-oriented object.

Another way to think of this is in terms of division of responsibilities. If you don't believe a particular class that knows of certain information should be responsible for dealing with that information, you can send a messenger containing the information to another class. In general, you should strive to move code to data at design time. But sometimes, you need to use messengers to move data to code at run time.

Messengers are usually immutable, but not always. An example of a mutable messenger is java.awt.event.MouseEvent, whose translatePoint method transforms the x and y positions contained in the MouseEvent by adding passed horizontal and vertical offsets. Immutables are described in Guideline 9. Exceptions are discussed in the Chapter on Exceptions. Events are discussed in the Guideline ? (about the Event Generator idiom).