Patrones de control de versiones de objetos

Question

Estoy tratando de modelar algunos de nuestros objetos en nuestro dominio y encontré un problema que algunos de estos objetos podrían ser versionados. es decir, el usuario podría crear nuevas versiones de objetos a lo largo de un período de tiempo. Entonces, necesito modelarlos en el programa. Creo que este es un problema común en el diseño SW.

Inicialmente, me lancé a la idea de imitar los conceptos de control de versiones de código fuente y propuse un concepto de objeto versionado y métodos como check-in, check-out, etc. Pero tengo la sensación de que no es "sistemático" como yo no explorar patrones (es decir, me siento como que cometen pecados como

• no escondí aspectos como buscar más de una solución
• mirar en la literatura que me darían referencias más sólidas, etc) .

Por lo tanto, mi problema actual es que para un modelado sistemático, necesito buscar patrones que aborden el problema del modelado de versiones, preferiblemente en la literatura. Y aprovecha lo mejor, por supuesto.

Así que busqué en Google esos patrones y solo encontré un Temporal Object pattern. Pero, no estaba seguro de si esto era realmente lo que quería. ¿Ustedes tienen alguna sugerencia sobre tales patrones?

[Self-Edit] Tal vez no describí bien el problema. Puede ver el problema similar a un problema de control de versiones de archivos de control de fuente. Tengo varios tipos de objetos (almacenados en la base de datos) que pueden tener varias versiones. Dentro de mi aplicación tengo que manejar todas estas versiones y también tendré que crear una nueva versión de los objetos (que eventualmente se almacenarán en la base de datos). Lo que estoy esperando es algún tipo de patrón citable con el que pueda modelar las interfaces para acceder/modificar/agregar nuevas versiones para estos objetos. La interfaz básica que podría surgir es IVersionedObject con métodos como checkout, checkin, undoCheckout, etc. Pero esta es mi propia idea al observar los sistemas de control de fuente. No creo que sea un patrón de diseño SW como tal. Entonces, esperamos algunos patrones de diseño muy bien documentados para el problema anterior.

Answer 1

¿No funcionaría algo así como un DataMapper personalizado?

doc = DocCatalog.get(docid, version); 

Suponiendo que se puede considerar cada objeto una materialización de lo que el objeto representa, en un momento dado (en el tiempo). En lugar de ser un objeto con una propiedad de "versión", el "correlador de versiones" está a cargo del datamapper/catalog/database; es decir, el objeto no conoce las versiones, pero sí el sistema de almacenamiento de objetos.

Guardar/almacenar un objeto en el DataMapper generaría una nueva versión:

// saves doc again after changing the title (which indeed stores a new version of it) 
doc.setTitle (newTitle); 
DocCatalog.save(doc); 

// gets a number indicating how many versions of the document exist 
i_versions = DocCatalog.getVersions(docid); 

// returns second-last version of the document 
doc = DocCatalog.get(docid, i_versions-1);