Объектно-ориентированный подход к обновлению
Мне было поручено поддерживать приложение, изначально написанное на VB6. С тех пор он был импортирован в VB .Net, и, мягко говоря, код не является объектно-ориентированным. Код пронизан классами, которые не содержат ничего, кроме общедоступных общих атрибутов (переменных) и методов (функций), в результате чего приложение не может открывать более одного проекта одновременно.
Проект состоит из XML-файла, который содержит общие настройки проекта, а также расположение в базе данных Access, которая содержит другие данные, связанные с проектом. С годами формат XML-файла был изменен, и была принята стратегия обновления и управления версиями. Выбранная стратегия выполняет обновление при открытии всякий раз, когда встречается старая версия. До сих пор обновления заключались только в изменении порядка данных в файле XML или внесении изменений в схему базы данных и перемещении данных из файла XML в базу данных.
Имея небольшой опыт работы с ООП, мне легко понять, что проект должен быть автономным объектом, с которым взаимодействуют другие объекты. Однако я не вижу, как применить выбранную стратегию обновления в ООП.
Проблема реализации выбранной стратегии обновления в ООП пока удерживает меня от использования ООП. Если у кого-то есть опыт выполнения такой задачи или есть рекомендации о том, как действовать, я буду признателен за любую помощь, которую вы можете предоставить.
Ответы 3
Создайте класс, который считывает XML-файл и предоставляет свойства / методы / и т. д. На основе данных в этом файле. Когда класс записывает XML-файл обратно, отформатируйте его так, как это требуется для новой версии.
Таким образом, в основном, класс сможет читать в текущей версии, а также во всех более старых версиях, но он всегда будет записывать новую версию.
Данные будут храниться во внутренних переменных класса, вместо того, чтобы сканировать XML-файл каждый раз, когда вам что-то нужно.
В этом случае также поможет добавление узла VERSION в ваш XML-файл.
Вы могли ответить на свой вопрос, когда использовали слово стратегия (то есть шаблон разработки стратегии).
Возможно, вы могли бы:
- Создайте класс проекта, который ничего не знает о преобразованиях, но принимает объект стратегии.
- Создайте иерархию классов для моделирования каждой возможной стратегии преобразования.
- Используйте фабричный метод для создания объекта проекта с правильной стратегией
Я не понимаю, почему это вызывает беспокойство. Ее можно было решить разными способами.
Если вы хотите создать объектно-ориентированный объект корпоративного типа, вы можете использовать любое подмножество следующего решения:
- Создайте интерфейс IProject, который описывает, как взаимодействуют другие объекты с проектом.
- Создайте текущую реализацию Проект, реализующий IProject и может читать и писать на текущая версия.
- Расширить проект для каждого прошлого версия, переопределив xml и методы чтения базы данных и наличие вызов конструктора написать, когда эти классы созданы
- Для большей предприимчивости создайте ProjectFactory, который обнаруживает версия файла и экземпляры правильная версия.
- Если требуются другие версии, переписать текущий проект, чтобы сделать то же, что и прошлые проекты, доступ к новой версии Project со всеми прочтениями, а затем звонком записывать.
Преимущество этого решения заключается в том, что вы можете продолжать блуждать с разными версиями, и для каждой новой версии требуется только возможность обновления с предыдущей версии, при этом все предыдущие версии каскадно переходят от предпоследней версии.
Хотя я согласен, что это, скорее всего, лучшее решение на данный момент, оно отказывается от обновления открытой стратегии в пользу обновления стратегии сохранения. В настоящее время обновление при сохранении будет работать, но по мере того, как мы переходим к решению, основанному на базе данных, этого, скорее всего, будет недостаточно.