Какую модель дизайна следует использовать для импорта/экспорта?

У меня есть объект события календаря. Я планирую сделать его совместимым с протоколами/форматами CalDAV/iCal/vCal, которые требуют, чтобы событие было сериализовано и де-сериализовано в разных форматах и из них.

Я мог бы написать набор ImportICal, ExportICal, ImportVCal, ExportVCal и т.д., но это не похоже на очень хороший подход, потому что, если формат vCal обновлен и т.д.

Кто-нибудь имел дело с этим типом ситуации импорта/экспорта раньше? Если да, то какой шаблон дизайна (если таковой имеется) в целом лучше всего?

Спасибо за вашу помощь!

Ответ 1

Я не особенно знаком с этими форматами, но я бы создал простой объект передачи данных, который представляет ваш общий объект событий календаря. Он ничего не делает, кроме хранения данных (псевдокод):

class CalendarEvent
{
    DateTime Date { get; }
    string Title { get; }
    string Description { get; }
}

Затем вы создаете интерфейс для CalendarEventReader и CalendarEventWriter (шаблон Стратегия и, возможно, шаблон Builder, вроде):

interface ICalendarEventReader
{
     CalendarEvent Read(Stream data);
     // Add additional methods if needed e.g.:
     string GetTitleOnly(Stream data);
}
interface ICalendarEventWriter
{
     Stream Write(CalendarEvent event);
     // Add additional methods if needed e.g.:
     Stream WriteSummaryOnly(CalendarEvent event);
}

Затем реалистичные реализации реализуют указанные выше интерфейсы. Один для каждого формата. Вы даже можете думать о том, что читатель и писатель в одном классе:

class CalDavConverter : ICalenderEventWriter, ICalendarEventReader
{
    ...
}

У вас тогда будет репозиторий (это шаблон Factory, возможно, с Синглтон), который поддерживает список реализаций ICalenderEventReader/Writer для разных форматов:

static class CalenderEventConverterRepository
{
    static ICalendarEventReader GetReader(string formatName /*or any other data upon wich to decide wich format is needed*/)
    { 
    ...
    }

    static ICalendarEventReader GetWriter(string formatName /*or any other data upon wich to decide wich format is needed*/)
    { 
    ...
    }
}

Ответ 2

Если формат vCal обновлен, вам придется изменить любой код, который вы написали, какой бы шаблон дизайна вы ни использовали (если только они не решили переключиться на нечто вроде ASN.1, в котором исправлены апгрейды).

Я бы создал интерфейс формата с методами импорта и экспорта и, возможно, метаданные и методы для проверки того, может ли случайный бит XML быть таким форматом. Затем для каждого другого формата у вас есть объект, который реализует этот интерфейс. Это своего рода "шаблон стратегии стратегии", но каждый формат представляет собой несколько стратегий для создания целостного набора вещей (импорт, экспорт, обнаружение), а не отдельные стратегические объекты.

Ответ 3

Обычный способ организации нескольких реализаций (протоколов календаря в вашем случае) с одним общим интерфейсом Bridge Pattern.