Как внести особый случай в дизайн API?

Question

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

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

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

void authenticate (String login, String password) throws AuthenticationException;

Но я не могу передать аутентификацию этому одному ресурсу с помощью этого метода.

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

Так что теперь мне нужно еще 2 метода для достижения необходимого результата:

String getAuthenticationURL () throws AuthenticationException;
void postAuthentication () throws AuthenticationException;

Если я добавлю эти методы в API, мне придется создавать их пустые реализации (или реализации, которые выдают исключение RuntimeException) во всех реализациях API для «обычных» ресурсов.

Если я не добавлю их в API, а добавлю их только в одну конкретную реализацию, тогда я нарушу саму идею унифицированного API.

Подход с этими двумя методами - только одно из по крайней мере нескольких возможных решений. Так что любые советы и предложения приветствуются.

Answer 1

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

Другой (возможно, лучший) метод, однако, может заключаться в создании абстрактного объекта «Аутентификация» с двумя API (две конкретные реализации). У одного будет ваш метод аутентификации, у другого - ваш get / post.

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

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

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

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

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

Answer 2

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

Таким образом, первым шагом для пользователя будет выбор правильного метода аутентификации, аутентификация и подготовка ресурса к использованию.