Соображения, касающиеся версий

Концепция поддержки версий, по сути, тесно связана с концепцией интерфейсов. При создании, определении и опубликовании интерфейса определяется контракт, или в более строгих терминах — стандарт.

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

Только представьте, какой бы возник хаос, если бы в любимом кафе могла функционировать WiFi-карта только одного единственного поставщика. Стандарты позволяют избежать подобных ситуаций.

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

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

Хотя это и не обязательно, но лучше ориентироваться на тех поставщиков, которые стараются захватить наибольшую часть рынка. В примере с 802.11 номера 802.11а, 802.1 lb и 802.1 lg представляют различные пересмотры стандарта.

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

Поэтому, завершив разработку контракта, снабдите его номером версии. Номер версии можно формировать различными способами. Для новых пересмотров интерфейса ему можно просто назначить новое имя — суть в том, чтобы никогда не менять исходный интерфейс. Возможно, уже приходилось сталкиваться с такой идиомой в мире СОМ.

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

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

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

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

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100