Ломая интерфейс

Question

Каковы наиболее важные рекомендации, которым нужно следовать, если вам нужно сломать интерфейс в приложении .NET? Как эти рекомендации меняются до и после развертывания приложения?

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

Если я просто добавляю новые методы в интерфейс, потребуется ли модификация / перекомпиляция только разработчикам, в то время как все клиенты продолжают работать без каких-либо изменений?

Как насчет переименования методов и переменных, это когда-нибудь нарушит интерфейс?

Одна сильная рекомендация, с которой я сталкивался в прошлом, - «никогда не ломай интерфейс». Но разве это не создает грязный дизайн, такой как IDocument, IDocument2, IDocument3, IDocument4, IDocument5, IDocument6 и т. Д., Как это видно в COM-библиотеке mshtml?

Answer 1

Это зависит от договора (подразумеваемого или явного) с потребителями вашего интерфейса.

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

Если вы ожидаете, что потребители будут перекомпилировать каждый раз, когда вы выпускаете новую библиотеку / приложение, вам нужно будет оказать им некоторую помощь, чтобы указать, какие изменения требуются, то, как вы справляетесь с этим, зависит от того, может ли изменение произойти во время обслуживания. старые функции / свойства. Если затем вы сможете разумно использовать [Obsolete («Использовать новый метод Blah вместо», false)] хотя бы в одном выпуске, за которым следует [Obsolete («...», true)] в следующем выпуске, это обеспечит чистую миграцию. путь

Если вы попытаетесь сохранить бинарную совместимость, тогда атрибуты «Устаревшие» позволят это сделать, не позволяя пользователям продолжать использовать устаревшую функциональность при перекомпиляции.

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

Answer 2

Это, безусловно, зависит от технологии. В COM (если не используется поздняя привязка IDispatch) вы можете безопасно добавлять новые методы в конец интерфейса, но не можете удалить или поменять ранее существующие методы без изменения GUID интерфейса. То же относится и к Microsoft RPC. Старые клиенты все еще могут быть довольны использованием интерфейса, так как он имеет только методы, о которых они знают.