Предложения для допуска изменения
Фон:
Я буду работать над инструментами, которые будут зависеть от быстро изменяющегося API и быстро изменяющий модель данных, над которой я буду иметь контроль дрейфа нуля.
Модель данных и изменения API распространены, проблема здесь - то, что мой код должен продолжить работать с током и всеми прошлыми версиями (т.е. 100%-я совместимость невыполнений обещания), потому что все продолжат использоваться внутренне.
Это должно также корректно ухудшиться, когда это сталкивается с недостающими/неизвестными функциями и т.д.
Инструменты будут записаны в C# с WinForms и для тестирования специального оборудования.
<Edit>
Моя цель была бы чем-то только близко к необходимости создать классы для добавления опций и когда изменения модели данных происходят, создают новый набор классов модели данных, которые будут созданы фабрикой на основе версии API.
Проблема для меня состоит в том, что будущие функции затем могут зависеть от определенных моделей данных, которые могут быть смешаны и подобраны (пока заключительная комбинация не достигнута). Как Вы обработали бы это корректно?
<Edit2>
Конечно, после того как продукт поставляется, я хотел бы снова использовать инструмент и просто добавить код для более новых продуктов. Прежде чем я запустил здесь, каждый цикл продукта означал переписывать (с нуля) все инструменты, что-то, что я стремлюсь предотвращать в будущем :)
</Edit>
Вопрос:
С какими методами проектирования и шаблонами Вы предложили бы или имели успех поддержать совместимость с несколькими версиями API/модели данных?
Какие ловушки я должен не упустить?
7 ответов
Здесь применимы практически все шаблоны SOLID , но особенно Принцип единой ответственности (SRP) и Принцип открытости / закрытости (OCP).
В OCP конкретно указано, что тип должен быть открытым для расширения, но закрытым для модификации - это звучит как хорошее место в вашем случае, потому что это будет способ гарантировать обратное совместимость.
SRP также очень полезен здесь, потому что это означает, что если класс выполняет только одно действие, и эта вещь становится устаревшей, это не влечет за собой множество других проблем. Его можно просто оставить умирать самому.
На более практическом уровне я бы посоветовал вам следовать двум принципам:
- Программируйте против интерфейсов (или даже лучше для обратной совместимости:
Одна идея, которая может быть полезна, - это «антикоррупционный слой», обсужденный Эриком Эвансом в его книге Domain Driven Design - ключевой мотивацией для шаблона является изоляция ваша система от изменений (и идиосинкразии) другой.
Вы упомянули, что код предназначен для тестирования специального оборудования. Изменится ли и ваш код (например, процедуры тестирования)? Будет ли ваш код тестировать круг сегодня и треугольник завтра или тот же самый основной круг, который развивается день ото дня?
Если есть постоянная точка, вокруг которой все движется, я бы начал с нее и написал оболочки для каждой версии API и модель данных, которые будут связаны с центром, учитывая методы, предложенные в других ответах.
Однако, если нет постоянной точки и все движется, я бы отказался от проекта! Это невозможно!
1) Множество юнит-тестов.
Каждый раз, когда вы пишете кусок кода, публикуйте множество юнит-тестов для кода, который будущие версии должны пройти для проверки.
Убедитесь, что тесты основаны на функциональных требованиях, то есть не на том, как написана функция, а на том, что она должна делать, чтобы не нарушить другой код.
Это поможет людям проверять изменения, которые нарушают другой код.
2) Требовать хорошей формальной спецификации всех API и моделей данных. Это гарантирует, что они будут разрабатываться более тщательно и что изменения не будут внесены волей-неволей без раздумий или причин.
Предоставляет ли ваш API / ваша модель данных метаданные? Если это так, было бы неплохо использовать это, чтобы сделать ваш код максимально независимым от изменений API. Например, если у вас есть возможность сгенерировать процедуры доступа к вашей модели данных в общем, используя схему модели данных, вам следует сделать это. Конечно, это имеет смысл только для определенных типов операций.
Напишите свою собственную обертку для интерфейса между вашим кодом и вещами, которые вы не контролируете. Тогда вы сможете писать свой код против API, которое выставляет обёртка, и вам останется только беспокоиться о взаимодействии в самой обёртке.
.Ваша лучшая ставка - чтобы API, который вы выставляете, требовал номер версии, чтобы прийти с запросом. Таким образом, вы можете выбрать правильный объект для создания. В худшем случае, каждое изменение прерывается, и в итоге вы получаете десятки классов. В лучшем случае, ваш дизайн может справиться с этим, и в конечном итоге время от времени вы получаете только отдельные классы. Наследование, вероятно, будет вашим другом в этом случае. Суть в том, что вы, по сути, облажались, если вам нужно поддерживать 100% обратную совместимость с быстро меняющимся API. В итоге вы либо получите один гигантский недостижимый класс, либо несколько классов, которые корректно реагируют на версионность
.