Яка хороша конструкція для забезпечення зворотної сумісності файлів між різними версіями програмного забезпечення?

Яка хороша конструкція для забезпечення зворотної сумісності типу файлів між різними версіями програмного забезпечення?

Наприклад, як 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 та способом обробки сумісності версій. Кожен блок має ідентифікатор, що описує тип блоку, і він містить деякі прапори, які повідомляють програмному забезпеченню, що робити, якщо він не може зрозуміти цей ідентифікатор. Наприклад, "ви не можете прочитати файл, якщо ви не розумієте цього блоку", або "ви можете прочитати файл, але не змінити його", або "ви можете змінити файл, але вам потрібно видалити цей блок". Для зворотної сумісності вашому програмному забезпеченню потрібно просто впоратися з ситуацією, коли очікуваних даних немає.

Спосіб зробити це можна за допомогою базового класу та інтерфейсу з основними функціями для обробки файлів. Потім використовуйте класи для кожної версії, яка поширюється на базовий клас, щоб обробити всі конкретні випадки версії. Функції, які можуть змінюватися, можуть бути віртуальними у базовому класі реферату, якщо існують лише конкретні версії. Коли вам потрібен клас для обробки файлу, використовуйте фабрику, яка отримує реалізовану для версії інтерфейс обробки файлів.

Я зробив це з XML, і він працює добре:

Просто дозвольте будь-якому елементу у вашому документі мати будь-які атрибути та будь-які підпункти (і коли порядок не важливий - у будь-якому порядку) Починаючи з першої версії програми - під час читання документа ігноруйте атрибути та піделементи, про які ви не знаєте в поточній версії.

Надалі, коли ви додаєте нову функцію до нової версії програми, тоді додайте атрибут або під елемент. Старіші версії ігнорують його. Нова версія повинна перевірити наявність атрибута чи піделемента та обробити його.

Наприклад, у вас є деякі елементи з текстами:

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

І в новій версії ви хочете додати колір до елемента, щоб додати атрибут color:

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

Старіша версія просто ігнорує colorатрибут при відкритті документа. Нові версії перевіряють наявність colorатрибута, а якщо його немає, призначає колір за замовчуванням.

За допомогою цього простого рішення ви матимете сумісність як назад, так і вперед.