異なるバージョンのソフトウェア間でファイルの後方互換性を許可するための優れた設計とは何ですか？

異なるバージョンのソフトウェア間でファイルタイプの後方互換性を許可するための優れた設計とは何ですか？

たとえば、Microsoftはどのようにして2007、2010、2013などの単語をすべての開いているdocxファイルに取得しますが、異なるエディションではより多くの/少ないデータを保存し、わずかに異なる方法でデータをすべて同じファイルタイプに保存できますあるバージョンで保存されたファイルは別のバージョンで開くことができますが、ファイルの特定の要素は古いバージョンでは使用できない可能性がありますか？

つまり、それを行うための本当に明白な方法は、

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

しかし、それは信じられないほどモノリシックで、あまり拡張性がなく、多くのコピー/貼り付けコードにつながる可能性があります。

だから私は、ファイルに存在する必要があるヘッダーなどの不変の構造、およびシリアル化/逆シリアル化に必要なメソッドを定義するすべてのバージョンのベースインターフェイスを使用することを考えていましたインターフェースを実装する新しいバージョンのクラスは古いバージョンを継承し、ファイルがほとんど同じであるため、変更されたもののみをオーバーライドします。

ファイルの構造についてはあまり気にしません。XMLを使用することは既に決まっているので、最初のスキーマは概して決定済みです。ただし、将来的には間違いなく変更されることになるので、これらの変更に容易に対応できるようにコードを設計できるようにしたいだけです。

PNGファイル形式と、バージョンの互換性の処理方法をご覧ください。すべてのブロックには、それがどのような種類のブロックであるかを示すIDがあり、そのIDを理解できない場合にソフトウェアに何をすべきかを伝えるフラグがあります。たとえば、「このブロックを理解していないとファイルを読み取ることができません」、「ファイルを読み取ることはできますが、変更することはできません」、「ファイルを変更することはできますが、このブロックを削除する必要があります」などです。下位互換性のために、ソフトウェアは、予想されるデータが存在しない状況を処理する必要があります。

これを行う方法は、ファイル処理のための基本機能を備えた基本クラスとインターフェイスを使用することです。次に、基本クラスから拡張される各バージョンのクラスを使用して、すべてのバージョン固有のケースを処理します。バージョン固有の実装しかない場合、変更可能な関数は抽象の基本クラスで仮想化できます。ファイルを処理するクラスが必要な場合は、ファイル処理インターフェイスのバージョン固有の実装を取得するファクトリを使用します。

私はXMLでこれを行いましたが、うまく機能します：

文書内のすべての要素に、属性とサブ要素を許可するだけです（順序が重要でない場合-任意の順序で）。プログラムの最初のバージョンから始まります-ドキュメントを読むとき、現在のバージョンでは知らない属性とサブ要素を無視します。

将来、プログラムの新しいバージョンに新しい機能を追加する場合は、属性またはサブ要素を追加してください。古いバージョンでは無視されます。新しいバージョンでは、属性またはサブ要素の押下をチェックし、それを処理する必要があります。

たとえば、テキスト付きのアイテムがいくつかあります。

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

そして新しいバージョンでは、属性を追加するためにアイテムに色を追加したいと思いますcolor：

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

古いバージョンは、colorドキュメントを開くときに属性を単に無視します。新しいバージョンは、color属性の押付けをチェックし、存在しない場合はデフォルトの色を割り当てます。

このシンプルなソリューションを使用すると、下位互換性と上位互換性の両方が得られます。