Предложения по изменению толерантности

Question

Справочная информация:
Я буду работать над инструментами, которые будут зависеть от быстро меняющегося API и быстро меняющейся модели данных, над которыми у меня будет нулевой контроль.

Изменения модели данных и API распространены, проблема в том, что мой код должен продолжать работать с текущими и всеми предыдущими версиями (т. Е. 100% -ная совместимость с обратными словами), потому что все будет по-прежнему использоваться внутри компании.

Он также должен изящно ухудшаться при обнаружении отсутствующих / неизвестных функций и т. Д.

Инструменты будут написаны на C # с WinForms и предназначены для тестирования нестандартного оборудования.

<Edit>

Моей целью было бы что-то близкое к тому, чтобы создавать классы для добавления функций, а когда происходят изменения модели данных, создавать новый набор классов моделей данных, которые будут создаваться фабрикой на основе версии API.

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

<Edit2>

Конечно, после того, как продукт будет отгружен, я хотел бы повторно использовать инструмент и просто добавить код для новых продуктов. До того, как я начал здесь, каждый цикл продуктов подразумевал переписывание (с нуля) всего инструментария, что я намерен предотвратить в будущем:)

</Edit>

Вопрос:
Какие методы проектирования и шаблоны вы бы предложили или имели успех для обеспечения совместимости с несколькими версиями API / модели данных?

Какие подводные камни я должен остерегаться?

Answer 1

Практически все шаблоны SOLID применимы здесь, но особенно Принцип Единой Ответственности (SRP) и Принцип Открытого / Закрытого (OCP).

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

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

На более практическом уровне я бы предложил вам следовать двум принципам:

• Программа для интерфейсов (или даже лучше для обратной совместимости: абстрактная базовая процедура )
• Сделать всех (или большинство) публичных участников виртуальными

TDD (или просто комплексный набор модульных тестов) поможет защитить вас от серьезных изменений.

Answer 2

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

Answer 3

Вы упомянули, что код предназначен для тестирования нестандартного оборудования. Изменится ли ваш код (т. Е. Процедуры тестирования)? Будет ли ваш код проверять круг сегодня и треугольник завтра или тот же базовый круг, который развивается изо дня в день?

Если есть постоянная точка, вокруг которой все движется, то я бы начал с нее и написал обертки для каждой версии API и модели данных, которые бы ссылались на центр, учитывая методы, предложенные в других ответах.

Однако, если нет постоянной точки и все движется, я бы отказался от проекта! Это невозможно сделать!

Answer 4

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

Answer 5

1) Множество юнит-тестов.

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

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

Это поможет людям проверять изменения, которые нарушают другой код.

2) Требовать хорошей формальной спецификации всех API и моделей данных. Это гарантирует, что они будут разработаны более тщательно, и что изменения не будут внесены в заблуждение без какой-либо мысли или причины.

Answer 6

Лучше всего, чтобы выставляемый вами API требовал номера версии для получения запроса. Таким образом, вы можете выбрать правильный объект для создания. В худшем случае каждое изменение ломается, и в итоге вы получаете десятки классов. В лучшем случае ваш дизайн может справиться с этим, и вы будете время от времени получать только отдельные классы. Наследование, вероятно, станет вашим другом в этом. Суть в том, что вы, в основном, облажались, если вам нужно поддерживать 100% -ную совместимость с быстро меняющимся API. Вы либо получите один гигантский не поддерживаемый класс, либо несколько классов, которые правильно реагируют на управление версиями.

Answer 7

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