如何用未知数量的字符串参数初始化类?

发布于 2024-08-20 23:15:45 字数 1284 浏览 3 评论 0原文

我正在开发 API,它应该提供对大量基于远程 Web 服务的资源的简单访问。

其中一些远程资源需要在交互之前传递特殊参数。例如,其中一个需要传递一对开发人员密钥,另一个需要一对密钥和唯一标识符。第三个根本不需要这些参数。我现在正在使用 3 个服务,但它们的数量可以扩大。

对于每个 Web 服务,我都有相应的 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:

相同的变体,但参数不是传递给工厂方法,而是传递给服务实例(例如在其 init() 方法中)。

优点:用户可以根据需要更改其服务的密钥,而无需创建同一服务的新实例。

缺点:方式较复杂,利润存疑。

您更喜欢哪种变体?为什么?欢迎您的变体。

I'm working on API which should provide simple access to number of remote web-service based resources.

Some of these remote resources requires special parameters to be passed before interaction. For example, one of them requires pair of developer's keys to be passed, another requires pair of keys and unique identifier. Third one doesn't require these parameters at all. I'm working with 3 services now but their number can be enlarged.

For each web-service I have correspondent implementation of my API. The problem is that I don't know how to introduce to my API possibility to pass unknown number of Strings with unknown meanings.

Some of my suggestions:

1.

ServiceFactory.createService (ServiceEnum type, Properties keys);

2.

ServiceFactory.createService (ServiceEnum type, ServiceParams params);

Where ServiceParams is a marker-interface. In this case I'll have some helper-class like this:

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 ();
} 

Pros: meaningful parameter names for each service.

Cons: if I provide support for fourth service then user will have to update factories module. In the first case user will only have to download new module.

3.

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

Pros: the most easy to use. User don't need to do any additional actions (like creating properties of ServiceParams).

Cons: the most unobvious way. User should know which set of params corresponds to the service he wants to create.

4-6:

the same variants but params are being passed not to factory method but to Service instance (in its init() method for example).

Pros: user can change keys for his service if he need without necessary to create new instance of the same service.

Cons: more complicated way, profit is questionable.

Which variant do you prefer? Why? Your variants are welcome.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

待"谢繁草 2024-08-27 23:15:45

您可以有两个工厂方法,一个传递包含参数的 Map,另一个不传递参数:

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

在这种情况下,调用者有责任获取正确的参数,但它为您提供了最大的灵活性。

You could have two factory methods, one where you pass a Map containing parameters, and the other without parameters:

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

In this case, it's the responsibility of the caller to get the parameters right, but it gives you maximal flexibility.

云胡 2024-08-27 23:15:45

我可能会选择选项 1,并将 Properties 替换为 Map,这是 Properties 用于其底层实现的内容。

I would probably go with option 1 and replace Properties with Map, which is what Properties uses for its underlying implementation.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文