Работа с несколькими стандартами в одной библиотеке классов - PullRequest
Новая
       17

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

0 голосов
/ 19 января 2009

В настоящее время я работаю над проектом, который будет поддерживать несколько спецификаций записи файлов (представьте, если вам нужно было поддерживать что-то вроде 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/

Ответы [ 2 ]

1 голос
/ 19 января 2009

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

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

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

0 голосов
/ 19 января 2009

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

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

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

...