15.6. Still More Separation

The design described in this chapter can have even a little more separation. You can split the Message s into two classes ("Splitters Can Be Lumped Easier Than Lumpers Can Be Split"). You can call the classes Command and Response (or ClientMessage and ServerMessage ). The two classes would behave in a similar manner, except they would reference different environments ( ClientEnvironment and ServerEnvironment ). They could both be of a common abstract type, such as Message , or they could remain completely separate types. The separation would clarify which messages were client generated and which were server generated.

Another possible design change deals with separation. Particular client messages in the current EnvisionWare system, generate multiple messages in response. The client requests are for a list of items, such as print jobs. The current system uses a protocol that works like an enumeration. The messages involved are as follows :

Request is InitialRequestMessage

Response is ListShortMessage

Request is SendNextMessage

Response is NextItemInListMessage

Request is SendNextMessage

Response is ListCompleteMessage

The server has a message queue mechanism for creating the appropriate responses to SendNextMessage . On the client side, the operation method keeps requesting items until it receives a ListCompleteMessage . As an example, GetJobsMessage results in multiple jobs. The sequence is as follows:

Request is GetJobsMessage

Response is ListStartMessage

Request is SendNextMessage

Response is PrintJobMessage

This repeats until all PrintJobs are returned

Request is SendNextMessage

Response is ListCompleteMessage

An abstraction has not yet been captured. There are both LogicalMessage s and a PhysicalMessage s. For messages that will return multiple items, these two are different. A LogicalMessage contains a collection of items that are generated from PhysicalMessage s. For messages not containing collections, the LogicalMessage and the PhysicalMessage are the same.

In this example, the ListStartMessage , PrintJobMessage , and ListCompleteMessage are PhysicalMessages . Using LogicalMessages , two new messages ” GetJobsLogicalMessage and PrintJobsLogicalMessage ”would be created. The operation on the client side would send a GetJobsLogicalMessage . The handle() method on the server would create a single PrintJobsLogicalMessage , rather than individual PrintJobMessages . The translation into corresponding PhysicalMessages and back from the PhysicalMessages would be handled by the framework.

If there were both LogicalMessage s and PhysicalMessage s, operation methods on the client and handler methods on the server would create and examine only LogicalMessage s. LogicalMessage s would create the corresponding PhysicalMessage s. If multiple items were expected as the return Message , the LogicalMessage would send the appropriate SendNextMessage s to receive all the PhysicalMessage s.

By using LogicalMessage s, you can change the underlying mechanism for handling multiple-item messages without affecting the operation methods. On a message-by-message basis, you can change the format from enumeration-style multiple physical messages to a single physical message that contained the multiple items.

Now comes the question as to whether this is a big enough issue to make the appropriate switch ("Separating Concerns Makes Smaller Concerns"). Clearly, there is a separation between LogicalMessage s and PhysicalMessage s. But if almost every LogicalMessage corresponded to a single PhysicalMessage , this separation, although noteworthy, provides little additional benefit. We would be handling parallel message spaces and simply transforming one message object into another.

If only one or two Message s contained multiple items, having specific code to deal with the enumeration is not a problem. If the percentage of multiple-item Message s becomes large (where large is relative to your level of tolerance), creating a separation between the two becomes beneficial.