responsabilidad por el almacenamiento

7

Un colega y yo hicimos una lluvia de ideas sobre dónde colocar la responsabilidad de un objeto para almacenarse en el disco en nuestro propio formato de archivo. Hay básicamente dos opciones:

  1. object.store (file)
  2. fileformatWriter.store (objeto)

El primero otorga la responsabilidad de la serialización en el disco al objeto en sí. Esto es similar al enfoque utilizado por Python Pickle.

El segundo agrupa la responsabilidad de representación en un objeto de escritor de formato de archivo. El objeto de datos es solo un contenedor de datos simple (eventualmente con métodos adicionales que no son relevantes para el almacenamiento).

Estamos de acuerdo con la segunda metodología, porque centraliza la lógica de escritura a partir de datos genéricos. También tenemos casos de objetos que implementan lógica compleja que necesita almacenar información mientras la lógica está en progreso. Para estos casos, el objeto fileformatwriter se puede pasar y utilizar como un delegado, llamando a las operaciones de almacenamiento en él. Con el primer patrón, el objeto lógico complejo aceptaría el archivo en bruto e implementaría la propia lógica de escritura.

El primer método, sin embargo, tiene la ventaja de que el objeto sabe cómo escribir y leer desde cualquier archivo que lo contenga, lo que también puede ser conveniente.

Me gustaría conocer tu opinión antes de comenzar una refactorización bastante compleja.

    
pregunta Stefano Borini 24.02.2011 - 10:32

7 respuestas

5

Preferiré la última opción, ya que sigue el principio de responsabilidad única , es decir, un objeto debe hacer una sola cosa y hacer Es mejor. Seguir el SRP en su caso asegurará que haya un acoplamiento flojo entre su funcionalidad central y el mecanismo de persistencia, de esa manera puede cambiar los detalles específicos del mecanismo de persistencia, por ejemplo. puede conservar su objeto como XML en lugar de un formato de archivo específico, proporcionar cifrado o almacenar el objeto en un servidor en lugar de su máquina local.

    
respondido por el Gaurav 24.02.2011 - 10:46
2

Definitivamente desacoplaría la capa de persistencia del objeto. Parece lógico, que la capa de persistencia tiene que ser intercambiable (archivo local, nube, caché distribuida, base de datos).

Por otra parte, si está utilizando un lenguaje con herencia múltiple, puede usar mixin pattern , para agregar esa capa de persistencia en el objeto, preservando así la interfaz object.store() , mientras se desacopla la persistencia.

    
respondido por el vartec 24.02.2011 - 12:32
1

Realmente depende de la estructura y las funciones del almacenamiento.

Si, por ejemplo, su almacenamiento es tonto y todo lo que tiene que hacer es escribir una sola instancia en un archivo separado, hay dos tareas a la mano. Como no puede almacenar el "objeto" en ningún medio, debe (1) serializarlo y luego (2) escribir bytes opacos en el archivo.

La primera tarea es responsabilidad del objeto. La segunda tarea es responsabilidad del almacenamiento. Así que en tus términos es algo así como

  

fileformatWriter.store (object.serialize ())

o algo así. Volver a cargar el objeto desde el almacenamiento es más complicado, ya que necesita determinar qué tipo de objeto era mirando el conjunto de bytes, esto me movería a un método de fábrica de clase. Algo como

  

object = Object.parse (fileformatReader.load ())

Esto implica que las serializaciones de diferentes Objetos juegan con las mismas reglas, para que nunca haya una ambigüedad.

    
respondido por el Dmitry Dvoinikov 24.02.2011 - 12:34
0

¿Es el almacenamiento una función central del objeto, o el almacenamiento de objetos es una función central de (parte de) su sistema? Si los primeros, hacen que los objetos se almacenen solos. En este último caso, haga que el sistema almacene los objetos.

    
respondido por el jwenting 24.02.2011 - 12:52
0

En mi opinión, depende de la complejidad de toda la aplicación. En los casos en que:

  • Tiene varios objetos que deben escribirse en el mismo archivo
  • Tu objeto para escribir ya es bastante complejo
  • Es posible que deba tener varios formatos diferentes para escribir un objeto.

Luego sugiero la segunda opción de crear un segundo objeto.

Pero definitivamente hay momentos en que la primera opción mantendrá las cosas simples en el código. También me gusta que un objeto sepa escribirse. Por lo general, comienzo con esta opción como mi opción principal, a menos que algún otro factor me lleve a la segunda opción (que termina siendo una situación común).

    
respondido por el jzd 24.02.2011 - 12:56
0

Puede crear un método de escritura (OutputStream) donde el objeto se almacena a sí mismo en esa secuencia, de lo que no dependerá de un objeto especial de almacenamiento de archivos y, al mismo tiempo, cuando desee guardar el objeto en el disco, no necesita saber nada. sobre ese objeto. Pero depende de cómo usarás este objeto después y quién restaurará el objeto.

    
respondido por el Dainius 24.02.2011 - 14:02
0

Estoy de acuerdo con el Principio de Responsabilidad Única en este: Un objeto no debe preocuparse por acciones fuera de su función directa. Si estuviera diseñando un modelo de serialización desde cero (en un modelo OO), crearía un Serializer y un SerializerOverride (los nombres pueden variar).

class Serializer {
   // Constructor
   public Serializer(StorageMedium sm);

   public boolean writeObject(Object o);
   public Object readObject();
   // other write/read methods if required
}

interface SerializerOverride {
   public bytes[] serialize();
   public Object deserialize();
}

Una implementación de writeObject podría tener el siguiente aspecto:

public boolean writeObject(Object o) {
   if (o instanceof SerializerOverride) {
      writeToStorage(((SerializerOverride)o).serialize)
   }
   else {
      // Serialize normally
   }
}

De esta manera, si el objeto tiene que hacer algo por sí mismo, puede hacerlo. Sin embargo, la mayoría de las veces no lo hará, y este tipo de diseño también permite que el objeto ignore por completo la serialización y se concentre en lo que realmente fue diseñado para hacer.

    
respondido por el Michael K 24.02.2011 - 15:58

Lea otras preguntas en las etiquetas