Управление версиями классов для поддержки обратной совместимости

Это довольно классическая проблема для любого агентства, которое работает с общественностью в любом качестве, особенно если это правительство или агентство, контролируемое государством. Решение нетривиальное, и, вероятно, потребуется значительная работа для его создания, а также последующего обслуживания.

Это работало для меня в прошлом, когда я имел дело с аналогичными проблемами для клиентов, но это может не сработать для вас, вам нужно будет набросать, чего вы пытаетесь достичь, и если это имеет смысл.

Есть несколько шаблонов, с которыми нужно ознакомиться (если вы еще этого не сделали):

1. Factory, которая уже упоминалась ранее
2. Композиция, которая, мы надеемся, избавит вас от некоторых неприятных проблем с наследованием.
3. Шаблон для отделения логики действия формы от версий

Есть две книги, которые очень хорошо объясняют это (и несколько других полезных):

1. Head First Design Patterns (не могу вспомнить сразу)
2. Шаблоны архитектуры корпоративных приложений (Фаулер)

Теперь к процессу, который я использовал в прошлом:

1. Начните с того, что возьмите все ваши текущие версии форм, разделите их на разные классы и найдите общие совпадения. Вы можете сделать это в черновом режиме или в соответствии с вашим текущим планом, чтобы иметь разные классы для каждой версии.
2. Выведите из этой структуры класса ряд «базовых» объектов, которые вы можете использовать в качестве корня наследования для каждого значительного набора версий формы. Их может быть несколько, но их должно быть меньше, чем всего объектов формы.
3. Теперь в каждом из этих базовых объектов сгруппируйте общие функции (например, структуры имен и адресов и т. д.) и абстрагируйте их в свою собственную иерархию классов, внедрите эту иерархию обратно в ваши базовые классы посредством внедрения конструктора.
4. Примените шаблон композиции к вашей иерархии базовых классов и работайте над тем, чтобы получить как можно больше общей структуры классов. В идеале ваши формы на этом этапе должны иметь минимальную функциональность, которая изменилась в каждой форме, и иметь конструктор, который принимает все общие (и, возможно, слегка отличающиеся) функции.
5. Примените шаблон шаблона сейчас, чтобы абстрагировать все общие «функциональные возможности» из ваших классов, такие как общая проверка и логика сохраняемости, снова используйте внедрение конструктора, чтобы вернуть эту функциональность в ваши базовые классы.
6. Извлеките определения адаптера интерфейса из ваших базовых классов и используйте их в качестве основы для вашего приложения для работы с вашими формами.
7. Создайте свои фабричные классы, чтобы справиться со всей кропотливой работой по настройке.

Надеюсь, что это дает вам некоторые идеи о том, что делать.

Если нельзя использовать наследование, «потому что поля в документе могут быть удалены», как вы справляетесь с этим в настоящее время?

В зависимости от деталей вашего дизайна вы должны иметь возможность переопределить поля, не используемые текущей версией документа (т. е. переопределить в подклассе для этого документа) и создать исключение NotSupportedException или подобное в реализации этого метода, если форма пытается присвоить значение. По аналогичной логике вы можете (и, вероятно, должны) использовать интерфейсы... просто зная, что конкретная реализация может вызвать исключение для свойства, которое она реализует, но которое не определено для этой версии пользовательского интерфейса.

Вы можете использовать шаблон Factory, чтобы вернуть соответствующий экземпляр объекта для данной версии формы.

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

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

Я бы реализовал это гораздо более слабо связанным способом — класс, содержащий два поля: версию и словарь. Когда данные изменяются так сильно, становится очень утомительно пытаться отслеживать свойства, которые теряются и добавляются. Со словарем вы можете просто проверить, существует ли ключ.

Без каких-либо дополнительных подробностей вашего кода, я думаю, вы, вероятно, могли бы попробовать идеи Decorator design pattern... Взгляните на эту статью: Избегайте чрезмерного создания подклассов с помощью шаблона проектирования Decorator

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