¿Cuál es un buen diseño para permitir la compatibilidad con versiones anteriores de archivos entre diferentes versiones de software?

Question

¿Cuál es un buen diseño para permitir la compatibilidad con versiones anteriores de archivos entre diferentes versiones de software?

#1 de gnasher729 (10 votos)
#2 de peer (3 votos)
#3 de user3123061 (2 votos)

13

¿Qué es un buen diseño para permitir la compatibilidad con versiones anteriores de un tipo de archivo entre diferentes versiones de software?

Por ejemplo, ¿cómo Microsoft obtiene Word 2007, 2010 y 2013, etc ... para todos los archivos docx abiertos, pero diferentes ediciones pueden guardar más / menos datos y guardar los datos de maneras ligeramente diferentes, todas al mismo tipo de archivo? ¿Y un archivo que se guarda en una versión puede abrirse en otra, pero ciertos elementos del archivo pueden no estar disponibles en versiones anteriores?

Quiero decir, la forma realmente obvia de hacerlo es tener algo como

private string openfile(string filename)
{
    File.Open(filename)

    ... some logic that gets a header from the file that will never change

    switch (fileversion)
        case 2007:
            .....
        case 2010
            .....
        case 2013
            .....
}

pero eso parece increíblemente monolítico, no muy extensible, y es probable que conduzca a una gran cantidad de código copiado / pegado.

Estaba pensando en utilizar una interfaz base para todas las versiones que define las estructuras inmutables, como el encabezado, que deben estar presentes en el archivo, y los métodos que deben estar disponibles para la serialización / deserialización, y luego la herencia múltiple. de modo que cada clase de nueva versión que implementa la interfaz hereda la versión anterior y solo reemplaza las cosas que han cambiado, ya que el archivo será el mismo, en su mayor parte.

Realmente no me preocupa la estructura del archivo, ya que ya se decidió que usaremos XML, y el esquema inicial es, en general, ya decidido. Sin embargo, no habrá duda de que habrá cambios en el futuro, y solo quiero poder diseñar el código de una manera que facilite la adaptación a estos cambios.

design file-handling backward-compatibility

pregunta JJBurgess 03.07.2015 - 10:04

3 respuestas

Lea otras preguntas en las etiquetas design file-handling backward-compatibility

¿Patrones para mantener la consistencia en un sistema distribuido de origen de eventos? Cómo admitir diferentes versiones de API

score 10 · Answer 1

Puede ver el formato de archivo PNG y cómo maneja la compatibilidad de versión. Cada bloque tiene una identificación que describe qué tipo de bloque es, y tiene algunas marcas que le indican al software qué hacer si no puede entender esa identificación. Por ejemplo, "no puede leer el archivo si no entiende este bloque", o "puede leer el archivo pero no modificarlo", o "puede modificar el archivo pero debe eliminar este bloque". Para compatibilidad con versiones anteriores, su software solo necesita manejar la situación cuando no hay datos esperados presentes.

score 3 · Answer 2

Una forma de hacerlo puede ser mediante el uso de una clase base y una interfaz con las funciones básicas para el manejo de sus archivos. Luego use clases para cada versión que se extiendan desde la clase base para manejar todos los casos específicos de la versión. Las funciones que pueden cambiar pueden ser virtuales en su clase base de resumen si solo hay implementaciones específicas de la versión. Cuando necesite una clase para manejar el archivo, use una fábrica que obtenga la implementación específica de la versión de la interfaz de manejo de archivos.

score 2 · Answer 3

He hecho esto con XML y funciona bien:

Simplemente permita que cualquier elemento de su documento tenga atributos y subelementos (y cuando el orden no es importante, en cualquier orden). A partir de la primera versión del programa: al leer un documento, ignore los atributos y subelementos que no conoce en la versión actual.

En el futuro, cuando agregue una nueva característica a la nueva versión del programa, agregue un atributo o subelemento. Las versiones anteriores lo ignorarán. La nueva versión debe verificar la presencia del atributo o subelemento y manejarla.

Por ejemplo, tienes algunos elementos con textos:

<item text="Hello, world!"/>

Y en la versión más reciente, le gustaría agregar color al elemento para que agregue el atributo color :

<item text="Hello, world!" color="008000"/>

La versión anterior simplemente ignorará el atributo color al abrir el documento. Las nuevas versiones comprueban la presencia del atributo color y, si no existe, asignan el color predeterminado.

Con esta solución simple, tendrá compatibilidad con versiones anteriores y posteriores.