Работа с несколькими стандартами в одной библиотеке классов

Question

В настоящее время я работаю над проектом, который будет поддерживать несколько спецификаций записи файлов (представьте, если бы вам пришлось поддерживать что-то вроде XML 1.0, XML 2.0, XML 3.0 и т.д.) под названием ADIF.В настоящее время существует два стандарта (версия 1.0 и версия 2.2.2), и оба они используются в коммерческих целях и оба все еще широко используются.

Версия спецификации 2.2.2 включает в себя большую часть версии 1.0, но есть некоторые незначительные отличия, которые исключают некоторое наследование и другие инструменты ООП.

Как бы вы организовали свой проект таким образом, чтобы поддерживать старые версии, но при этом продолжать соответствовать новым стандартам?

• Пространства имен (Standard.Version1, Standard.Version222, Standard.Version223 (следующая версия?) и т.д.) В одной библиотеке классов?Кажется неряшливым.
• Отдельная библиотека классов для каждого в одном и том же решении (Version222.dll, Version223.dll и т.д.)?Кажется чрезмерным.
• и т.д.

Я действительно намерен реализовать некоторый код, который будет преобразовываться из одной версии в другую.

По сути, я ищу несколько советов о том, как наилучшим образом организовать проект такого типа.

http://www.adif.org/

Answer 1

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

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

т. е.ваш API версии 2.2.2 будет принимать только объекты версии 2.2.2, чтобы предотвратить проблемы в библиотеке.Удачи во всем, что вы реализуете :)

Answer 2

Версия спецификации 2.2.2 включает в себя большую часть версии 1.0, но есть некоторые незначительные отличия, которые исключают некоторое наследование и другие инструменты ООП.

Композиция объектов может быть гораздо более мощным инструментом для ООП, чем наследование, которым ИМО злоупотребляет.

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