474 | Chapter 13: Symmetric Proxy Pattern
Key Features
Most of the key features of the Symmetric Proxy pattern have been described, but
there are a few more. In this section we’ll summarize:
- A player interface that includes move-taking, move display, and outcome methods
- A referee class based on a Template Method for determining game outcome
- Synchronizing cell between the UI and player
- Mirrored referee, proxy and player objects
Having discussed the player interface and referee concepts, we are left with two key
elements to discuss before going on to look at key OOP concepts in this design pat-
tern. First, we need to take a closer look at the synchronizing cell, and where the cell
goes in the overall scheme of things. Second, we need to look more closely at the
concept of a proxy object.
The cell
Heliotis and Schreiner refer to the cell in their design as a monitored single-element
queue placed between the player object and the graphical elements. In most cases,
the graphical elements would be the UI. In looking at the sequence diagram for par-
allel turn taking, the cells are placed between the proxy players, one for each player.
For simultaneous turns, two cells are used; one for each player making a move at the
same time.
Looking at the code used by Heliotis and Schreiner, an alternative implementation
came to mind in the form of a remote shared object available through Flash Media
Server 2 (FMS2). The shared object could act as the synchronizing mechanism, ensur-
ing that both sides had the same information at the same time. As soon as either
player entered a move, it would immediately be available to the proxy object as a
move. The “cell” itself would be in the player in a function waiting for both sides to
move. In effect, the synchronizing role of the cell has been taken over by the shared
object. Setting the move in a shared object would fall to a FMS2 server-side script.
The proxy
Because using FMS2 takes care of the synchronizing problems and is immediately
available to connected clients through a client-side method, we end up with a situa-
tion where we have to ask whether we really need a separate object for the proxies.
Instead of creating four player objects, would it be possible to create two? Each
player object, based on a common interface, would contain both the real player and
the proxy player. This is an androgynous variation of the Symmetric Proxy design
pattern, but conceptually, it’s virtually identical. Figure 13-4 shows an object dia-
gram of this variation.