Rolling out a ROApp - Programming GPS and OpenStreetMap Applications with Java - page 173

ROServer.identify creates a ServerObject for the client, but LondonChase
.identify has no reference to it. This problem was avoided on page 149 by
mapping the client directly to its SO. Therefore, the ID is retrieved in two
steps:

// 1. look up ServerObject via client
ServerObject so = connectedClients.get( client );
...
// 2. get identity again
Object ID = so.getIdentity();

The server object should be equal to a server object stored in candidates ,
which can be verified via:

// 3. look up ServerObject via ID
ServerPlayer
player = (ServerPlayer) roBox.getCandidate( ID );
// 4. assertion
if ( !so.equals( player )) { ... }

So, in the end, the server implementation is a great help for the application
designer. But how did the ServerPlayer get in there?

12.4.1 ServerPlayerExtendsServerObject
If you recall the pairing of the four-layer architecture,

RealObject | RealObjectsServer

/\ ---+--- /\

SpecificRealObject | SpecificRealObjectsApplication

you can tell that the application knows more about specific real objects
than the server could ever know. Looking at the four-layer architecture, one
might conclude that the server can not deal with specific objects created
especially for an application. It would be helpful (and clean) to create
a server-side player to hold specific information in addition to the real-
object attributes; this can be achieved with OO! Just like the identification
method, the creation of a server-side object can be overridden. This time

the clue is not to invoke the super method:

// RealObjectsServer implementation:
protected ServerObject
createServerObject( RemoteObject client )
{ ... return new ServerObject( client, server ) ... }

// RealObjectsApplication implementation:
@Override // .. and hide super.createServerObject
protected ServerPlayer // is a ServerObject
createServerObject( RemoteObject client )
{ ... return new ServerPlayer( client, server ) ... }