Prefactoring

15.6. Still More Separation

The design described in this chapter can have even a little more separation. You can split the Messages 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 ...