Что предпочтительный путь состоит в том, чтобы сохранить различные версии данных?

Когда Вы пишете приложение, которое должно читать и работать с двумя версиями данных таким же образом, что лучший способ состоит в том, чтобы структурировать Ваши классы для представления тех данных. Я придумал три сценария:

  1. Общая база / Определенные Дети
  2. Объединение данных
  3. Отличные структуры

Версия 1 Автомобильный пример

byte DoorCount
int Color
byte HasMoonroof
byte HasSpoiler
float EngineSize
byte CylinderCount

Версия 2 Автомобиль

byte DoorCount
int Color
enum:int MoonRoofType
enum:int TrunkAccessories
enum:int EngineType

Общая база / Определенные Дети

С этим методом существует базовый класс общих полей между двумя версиями данных и дочернего класса для каждой версии данных.

class Car {
    byte DoorCount;
    int Color;
}

class CarVersion1 : Car {
    byte HasMoonroof;
    byte HasSpoiler;
    float EngineSize;
    byte CylinderCount;
}

class CarVersion2 : Car {
    int MoonRoofType;
    int TrunkAccessories;
    int EngineType;
}

Преимущества

  • Парадигма ООП

Слабые места

  • Существующие дочерние классы должны будут измениться, если новая версия выпущена, который удаляет общее поле
  • Данные для одной концептуальной единицы разделяются между двумя определениями не из-за любого подразделения, значимого для себя.

Объединение данных

Здесь, Автомобиль определяется как объединение полей Автомобиля через все версии данных.

class Car {
    CarVersion version;
    byte DoorCount;
    int Color;
    int MoonRoofType;     //boolean if Version 1
    int TrunkAccessories; //boolean if Version 1
    int EngineType;       //CylinderCount if Version 1
    float EngineSize;     //Not used if Version2
}

Преимущества

  • Гм... Все находится в одном месте.

Слабые места

  • Принудительный случай управляемый код.
  • Трудный поддержать то, когда другая версия является выпуском или наследием, удалено.
  • Трудный осмыслять. Значения полей изменяются на основе версии.

Отличные структуры

Здесь структуры не имеют никаких отношений ООП друг к другу. Однако интерфейсы могут быть реализованы обоими классами, если/когда код ожидает рассматривать их тем же способом.

class CarVersion1 {
    byte DoorCount;
    int Color;
    byte HasMoonroof;
    byte HasSpoiler;
    float EngineSize;
    byte CylinderCount;
}

class CarVersion2 {
    byte DoorCount;
    int Color;
    int MoonRoofType;
    int TrunkAccessories;
    int EngineType;
}

Преимущества

  • Простой подход
  • Легкий поддержать, если новая версия добавляется или наследие удалено.

Слабые места

  • Это - антишаблон.

Существует ли лучший способ, которым я не думал? Вероятно, очевидно, что я одобряю последнюю методологию, но первый лучше?

5
задан 2 revs 23 January 2010 в 20:53
поделиться

3 ответа

Почему третий вариант, отдельные структуры для каждой версии, плохая идея или анти-шаблон?

Если две версии структур данных используются в общем приложении / Модуль - им придется реализовать тот же интерфейс. Период. Определенно несостоятельно написать два разных приложения модули для обработки двух разных версий структуры данных. Тот факт, что базовая модель данных чрезвычайно отличается, должна быть неактуальной. В конце концов, целью письма объектов является достижение практического уровня инкапсуляции.

Как вы продолжите запись кода таким образом, вы должны в конечном итоге найти места, где код в обоих классах похожи или избыточно. Если вы перемещаете эти общие кусочки кода из различных классов версии, вы можете в конечном итоге в конечном итоге с классами версий, которые не только реализуют тот же интерфейс, но также могут реализовать один и тот же базовый / абстрактный класс. Вуаля, вы нашли свой путь к вашему «первому» варианту.

Я думаю, что это лучший путь в среде с постоянно развивающимися данными. Требуется некоторая усердие и «смотрит» на более старый код, но стоит преимуществ ясности кода и многоразовых компонентов.

Другая мысль: в вашем примере базовый класс «автомобиль». На мой взгляд, вряд ли когда-либо оказывается, что базовый класс настолько «рядом» к этому наследникам. Более реалистичный набор базовых классов или интерфейсов может быть «версией», «обновлен», «OptionContainer» и т. Д. Просто говорил от моего опыта, YMMV.

1
ответ дан 15 December 2019 в 06:26
поделиться

используйте второй подход и улучшайте его с помощью интерфейсов. помните, что вы можете реализовать несколько "версий" интерфейсов, что дает вам возможность обратной совместимости! я надеюсь, что вы получите то, что я хотел сказать ;)

1
ответ дан 15 December 2019 в 06:26
поделиться

Соответствие следующему требованию:

приложение, которое необходимо прочитать и работать с двумя версиями данных одинаково

, я бы сказал, что самое главное, что вы Воронка вся логика через слой абстракции данных, так что ни одна из вашей логики не придется заботиться о том, используете ли вы 1, 2 или N данных.

Один из способов сделать это - иметь только один класс данных, то есть самая «заполненная» версия данных. По сути, это было бы MOONROOFTYPE , но не Hasmoonroof , поскольку это может быть выведено. Этот класс также не должен иметь какие-либо устаревшие свойства, поскольку это зависит от уровня абстракции данных, чтобы решить, какие значения по умолчанию должны быть.

В конце концов у вас будет приложение, которое вообще не заботится о версиях данных.

Что касается слоя абстракции данных, вы можете или не хотеть иметь классы данных для каждой версии. Скорее всего, все, что вам нужно, это один класс для каждой версии структуры данных с Сохранить и нагрузки Методы хранения / создания экземпляров данных, используемых вашей логикой приложения.

1
ответ дан 15 December 2019 в 06:26
поделиться
Другие вопросы по тегам:

Похожие вопросы: