3

私は、多数のリモート Web サービス ベースのリソースへの簡単なアクセスを提供する API に取り組んでいます。

これらのリモート リソースの一部では、対話の前に特別なパラメーターを渡す必要があります。たとえば、1 つは開発者のキーのペアを渡す必要があり、もう 1 つはキーのペアと一意の識別子を必要とします。3 番目のものは、これらのパラメーターをまったく必要としません。現在、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 ();
}

長所: 各サービスの意味のあるパラメーター名。

短所: 4 番目のサービスをサポートする場合、ユーザーは factory モジュールを更新する必要があります。最初のケースでは、ユーザーは新しいモジュールをダウンロードするだけです。

3.

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

長所：最も使いやすい。ユーザーは追加の操作を行う必要はありません (ServiceParams のプロパティの作成など)。

短所：最も目立たない方法。ユーザーは、作成したいサービスに対応するパラメーターのセットを知っている必要があります。

4-6:

同じバリアントですが、params はファクトリ メソッドではなく Service インスタンス (たとえば、その init() メソッド) に渡されます。

長所: ユーザーは、同じサービスの新しいインスタンスを作成する必要がなくても、必要に応じてサービスのキーを変更できます。

短所：より複雑な方法で、利益が疑わしい.

どのバリアントが好きですか? なんで？あなたのバリエーションは大歓迎です。

4

2 に答える 2

3

2 つのファクトリ メソッドを使用できます。1 つはMap含まれるパラメーターを渡し、もう 1 つはパラメーターなしで渡します。

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

この場合、適切なパラメーターを取得するのは呼び出し元の責任ですが、最大限の柔軟性が得られます。

于 2010-02-09T13:05:24.540 に答える
1

おそらくオプション 1 を使用し、Properties が基になる実装に使用する にProperties置き換えます。Map

于 2010-02-09T13:14:43.143 に答える