¿Cómo 'de-serializar' una clase derivada de datos serializados?

Question

¿Cómo 'de-serializa' una clase derivada de datos serializados? O tal vez debería decir, ¿hay una mejor manera de "deserializar" los datos en clases derivadas?

Por ejemplo, supongamos que tiene una clase base virtual pura (B) heredada por otras tres clases, X, Y y Z. Además, tenemos un método, serialize(), que traducirá X: B, Y: B y Z: B en datos serializados.

De esta manera se puede pasar a través de un socket, un tubo con nombre, etc. a un proceso remoto.

El problema que tengo es, ¿cómo creamos un objeto apropiado a partir de los datos serializados?

La única solución que se me ocurre es incluir un identificador en los datos serializados que indica el tipo de objeto derivado final. Donde el receptor, primero analiza el campo de tipo derivado de los datos serializados, y luego usa una declaración de conmutación (o algún tipo de lógica como esa) para invocar el constructor apropiado.

Por ejemplo:

B deserialize(serial_data) 
{ 
    parse the derived type from the serial_data 

    switch (derived type) 
     case X 
      return X(serial_data) 
     case Y 
      return Y(serial_data) 
     case Z 
      return Z(serial_data) 
} 

Así que después de conocer el tipo de objeto derivado que invocar el constructor de tipo derivada adecuada.

Sin embargo, esto se siente incómodo y engorroso. Espero que haya una manera más elocuente de hacer esto. ¿Esta ahí?

Answer 1

De hecho, es un problema más general que la serialización llamada Virtual Constructor.

El enfoque tradicional es un Factory, que en función de un ID devuelve el tipo derivado correcto. Hay dos soluciones:

• el método switch Como habrá notado, sin embargo es necesario asignar en el montón
• el método prototype

El método prototipo va así:

// Cloneability 
class Base 
{ 
public: 
    virtual Base* clone() const = 0; 
}; 

class Derived: public Base 
{ 
public: 
    virtual Derived* clone() const { return new Derived(*this); } 
}; 

// Factory 
class Factory 
{ 
public: 
    Base* get(std::string const& id) const; 
    void set(std::string const& id, Base* exemplar); 

private: 
    typedef std::map < std::string, Base* > exemplars_type; 
    exemplars_type mExemplars; 
}; 

Es algo tradicional hacer que el Factory sea singleton, pero es completamente diferente.

Para la deserialización adecuada, es más fácil si tiene un método virtual deserialize para llamar al objeto.

EDITAR: ¿Cómo funciona la fábrica?

En C++ no puede crear un tipo que no conozca.La idea anterior es, por lo tanto, que la tarea de construir un objeto Derived se da a la clase Derived, mediante el método clone.

Luego viene el Factory. Vamos a usar un map que asociará una "etiqueta" (por ejemplo, "Derived") a una instancia de un objeto (digamos Derived aquí).

Factory factory; 
Derived derived; 
factory.set("Derived", &derived); 

Ahora, cuando queremos crear un objeto que el tipo no sabemos en tiempo de compilación (porque el tipo se decide sobre la marcha), se pasa una etiqueta a la fábrica y pedir un objeto en regreso.

std::unique_ptr<Base> base = factory.get("Derived"); 

Bajo la cubierta, la Factory se encuentra el Base* asociado a la etiqueta "Derived" e invocar el método del objeto clone. Esto realmente (aquí) creará un objeto de tipo de tiempo de ejecución Derived.

Podemos comprobar esto mediante el operador typeid:

assert(typeid(base) == typeid(Derived)); 

Answer 2

 
inmemory: 
-------- 
type1 { 
    chartype a; 
    inttype b; 
}; 
serialize(new type1()); 

serialized(ignore { and ,): 
--------------------------- 
type1id,len{chartypeid,adata,inttypeid,bdata} 

supongo, en un protocolo de serialización ideales, cada tipo no primitivo necesita ser prefijado con typeid, len. Incluso si serializas un tipo único que no se deriva de nada, agregarías un ID de tipo, porque el otro extremo debe saber qué tipo obtiene (independientemente de la estructura de herencia). Por lo tanto, debe mencionar identificadores de clase derivados en la serialización, ya que lógicamente son tipos diferentes. Corrígeme si estoy equivocado.