Design – a good design for allowing backwards compatibility of files between different versions of software

backward compatibilitydesignfile handling

What is a good design for allowing backwards compatibility of a file type between different versions of software?

For instance, how does microsoft get word 2007, 2010 and 2013 etc… to all open docx files, but different editions can save more / less data and save the data in slightly different ways, all to the same file type, and a file that is saved in one version can be opened in another, but certain elements of the file might not be available in older versions?

I mean, the really obvious way to do it is to have something like

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
            .....
}

but that seems incredibly monolithic, not very extensible, and likely to lead to a lot of copy / pasted code.

So I was thinking of using a base interface for all versions which defines the immutable structures, such as the header, that need to be present in the file, and methods that need to be available for serialisation / deserialisation, then multiple inheritance so that each new version's class that implements the interface inherits the old version, and only overrides stuff that has changed, since the file will be the same, for the most part.

I'm not really bothered about the structure of the file, since it's already decided that we'll be using XML, and the initial schema is, by and large, already decided. However there will no doubt be changes to it in the future, and I just want to be able to design the code in a way that makes it easy to accommodate these changes.

Best Answer

You might have a look at the PNG file format and how it handles version compatibility. Every block has an id describing what kind of block it is, and it has some flags that tell the software what to do if it cannot understand that id. For example "you cannot read the file if you don't understand this block", or "you can read the file but not modify it", or "you can modify the file but you have to delete this block". For backward compatibility, your software just needs to handle the situation when any expected data is not present.

Related Solutions

Class Design – Method for Loading Data from Multiple File Formats

Strategy Pattern

The strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

Here's some excellent examples of the strategy pattern

As you can see from the 1st link above, you can detect the file type in the header in your main method, and then feed the correct version of the Strategy into the context and then call the context.

If you really want to you could write a Factory Method to automatically create your context.

http://www.dofactory.com/Patterns/PatternFactory.aspx#_self2

So you could call something like the following

var context = FileFactory.CreateContext(myFile);
context.Parse();

A factory method might be a little overkill for this however, this would be a judgement call on your part. However using the strategy pattern as above gives you the flexibility to add any number of new file types to parse. Additionally the factory will give you the ability to abstract away all of the polymorphism from your logic code.

Edit

Here is what you would end up with using a strategy pattern combined with a Factory Method.

public interface IFileParserStrategy
{
    IList<Person>  Parse(String path);
}


public class FileFormatNo1 : IFileParserStrategy
{    
   private string _path; 
    public FileFormatNo1(String path){
      _path = path;
    }

    public IList<Person> Parse()
    {
        // Actual Logic for handling File Format #1 
        // and returning a IList<Person>   
    }
}

public class FileFormatNo2 : IFileParserStrategy
{     
    private string _path; 
    public FileFormatNo1(String path){
      _path = path;
    }

    public IList<Person> Parse(String path)
    {
        // Actual Logic for handling File Format 2
        // and returning a IList<Person>   
    }
}

public interface IFileParserContext 
{ 
    public IList<Person> Parse();
}

public class FileParserContext : IFileParserContext
{
    private IFileParserStrategy _strategy;

     public FileParserContext(IFileParserStrategy fileParserStrategy)
     {
         _strategy = fileParserStrategy;
     }

     public IList<Person> Parse()
     {
         return _strategy.Parse();
     }
}

public static class FileParserFactory
{
    public static IFileParserContext CreateContext(String path)
    {
           FileParserContext context = null;

           var checkFileFormat = File.ReadAllLines();

            if(checkFileFormat.Contains("FileFormatNo1"))
              context = new FileParserContext(new FileFormatNo1(path));

            if(checkFileFormat.Contains("FileFormatNo2"))
               context = new FileParserContext(new FileFormatNo2(path));

             if(context == null)
                throw new FileFormatException("File is not in a readable state");

             return context;            
    }       
}


public static void Main()
{    
    var filePath = "someFile.txt";
    var context = FileParserFactory.CreateContext(filePath);    
    var personList = context.Parse();
}

Update

You could modify the above strategy to pass around a FileStream if you only wanted to open the file once. You could modify FileParserFactory.CreateContext to accept a FileStream for its parameter, and refactor the strategies to accept the FileStream instead of the filePath.

public static void Main()
{    
    var filePath = "someFile.txt";
    List<Person> personList;

    using(var fileStream = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.Read)) 
    {
        var context = FileParserFactory.CreateContext(fileStream);    
        personList = context.Parse();
    }        
}

Multithreading – Multithreaded File Copy in .NET

This depends on what the limiting factor is, doesnt it? If the bottleneck is the utility program, then sure, running more than one copy or using more threads will speed things up. If the network is the limiting factor, then adding multiple instances of the utility isnt going to help since you still will be stuck moving at most X bytes per second. In fact it might hurt because you have the additional overhead of a second copy of the app. Same with disk-IO. You can only copy as fast as either machine can read from and write to disk. If thats already max'd out, adding copies isnt going to help.

What you need to do is test to see what the bottleneck is, and go from there.

Best Answer

Related Solutions

Class Design – Method for Loading Data from Multiple File Formats

Multithreading – Multithreaded File Copy in .NET

Related Topic