Как начать класс с неизвестным количеством параметров String? - PullRequest
Новая
       30

Как начать класс с неизвестным количеством параметров String?

3 голосов
/ 09 февраля 2010

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

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

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

Некоторые из моих предложений:

1 

ServiceFactory.createService (ServiceEnum type, Properties keys);

2 

ServiceFactory.createService (ServiceEnum type, ServiceParams params);

Где ServiceParams - это маркер-интерфейс. В этом случае у меня будет некоторый вспомогательный класс, подобный этому: 

public class ServiceHelper {

   public static ServiceParams createFirstServiceParams (String secretKey, String publicKey);

   public static ServiceParams createSecondServiceParams (String secretKey, String publicKey, String uid);

   public static ServiceParams createThirdServiceParams ();
}

Плюсы: значимые имена параметров для каждого сервиса.

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

3. 

ServiceFactory.createService (ServiceEnum type, String ... params);

Плюсы: самый простой в использовании. Пользователю не нужно выполнять никаких дополнительных действий (например, создавать свойства ServiceParams).

Минусы: самый неочевидный способ. Пользователь должен знать, какой набор параметров соответствует услуге, которую он хочет создать.

4-6:

те же самые варианты, но параметры передаются не фабричному методу, а экземпляру Service (например, в его методе init ()).

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

Минусы: более сложный способ, прибыль сомнительна.

Какой вариант вы предпочитаете? Зачем? Ваши варианты приветствуются.

Ответы [ 2 ]

3 голосов
/ 09 февраля 2010

У вас может быть два заводских метода, один из которых вы передаете Map, содержащий параметры, а другой без параметров: 

ServiceFactory.createService(ServiceEnum type);
ServiceFactory.createService(ServiceEnum type, Map<String,?> params);

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

1 голос
/ 09 февраля 2010

Я бы, вероятно, пошел с вариантом 1 и заменил Properties на Map, который Properties использует для своей базовой реализации.

...