Serialization aims at encoding objects in a way that can be manipulated outside of the framework.
This operation (and its reverse : deserialization) would be valuable from being applied on :
Therefore objects can be :
Because commands reference data, serializing commands indirectly leads to serializing data.
However in order to avoid sending several times the same data when performing for instance a complete game state graph update, data references should be introduced.
An easy means to solve this issue is to associate a unique identifier to all data.
Possible typical choices are either a number or a string : the string is chosen for its better accurateness and debug facilities.
Object references associated with their identifiers are stored in an object called a resolver (probably within a hashtable) responsible for retrieving an object based on its identifier.
A consumer called an output defines how commands are serialized.
A producer called an input deserializes commands previously serialized via its matching output.
The first step to set up an input and/or an output deals with opening a medium : file, network, etc.
To decouple this step from the others in order to provide the maximum flexibility an acceptor-connector like pattern is used.
Acceptors and connectors can therefore be viewed as factories for creating inputs and outputs, thus handling the whole creation process.
