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 :

  • commands
  • data

Therefore objects can be :

  • sent over a network
  • written to a file
  • persisted within a database


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.


database, file, etc.

framework save/load