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

Question

Я хочу создать библиотеку классов для некоторых стандартов. Эти стандарты обновляются ежегодно (не обязательно каждый год, может также потребоваться 3-4 года). Я хочу поддерживать старые версии также. Каков наилучший способ сделать это?

В настоящее время я думаю о следующей структуре:

StandardName (namespace) --> Year(namespace) --> actual implementation of particular standards Class

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

Answer 1

Требования к вопросу:

• Является ли стандарт обратно совместимым?
• Должны ли несколько версий стандарта сосуществовать в одном приложении?

Если ваш стандарт обратно совместим, вы можете наследовать классы от старых версий при реализации новых.

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

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

Итог: если это вообще возможно, я бы избегал разделения пространства имен, но вам это может понадобиться.

Answer 2

Я думаю, что правильная инкапсуляция вот ключ.

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

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

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

Answer 3

В зависимости от вашего стандарта ОО справляется с этим хорошо или не очень хорошо. Самая базовая поддержка - это интерфейс, который должны реализовать ваши классы. Это означает, что повторное использование невозможно, если вы не начнете использовать делегатов в своих реализациях.

Или, если стандарт только растет (т. Е. Старые функциональные возможности никогда не меняются), то вы можете полностью это поддерживать, наследуя.

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

Answer 4

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

Если это так, то я бы предпочел сохранить каждое значение в базе данных вместе со столбцом DateTime Applied, поэтому мне придется выполнить следующий запрос для определения текущего значения:

SELECT TOP 1 Value WHERE Key = %A AND Applied <= GETDATE() ORDER BY Applied DESC

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

Answer 5

Возможно, вашим новым классам нужны новые имена, потому что они делают что-то другое.

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

Answer 6

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

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