Программирование API и программирование на интерфейс

Question

Часто рекомендуется «программировать на интерфейс, а не на реализацию». Это полезно для разделения проблем и помогает в модульном тестировании. Однако я думал о программировании API.

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

Мой вопрос: как избежать такой проблемы (или уменьшить влияние таких изменений), или это неизбежно? Я не программист API и хотел бы узнать лучшие практики здесь. Мне кажется, что изменение интерфейса, который существовал в течение длительного времени и широко используется, является плохой идеей.

Answer 1

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

В случае сервисов эти API-интерфейсы не должны нарушаться.Добавление интерфейсов для них не повлияет на существующих потребителей.

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

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

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

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

Answer 2

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

Цитировать MSDN :

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

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