0

既存の REST API 用の Java API ライブラリを作成しています。

REST API にはいくつかの postOperations (getPosts、getUserPosts、getGlobalPosts など) があるため、それを公開する postOperations のクラスがあります。ここで、パラメーターのグループ (generalParameters) を追加するオプションをすべての操作に追加する必要があります。

より良い解決策は何だと思いますか?

  1. 現在の関数にパラメーターを追加します。これは、ユーザーが null を渡す必要がある場合があることを意味します (実際には 80% の時間です)。
  2. 2 つのパラメーターを取得するすべての操作にオーバーロード関数を追加します (これは、クラスに 6 ～ 7 個のオーバーロード メソッドを追加することを意味します)。

私は両方の方法が機能することを知っています。そして、ほとんどのアプリケーションでは大きな問題ではありませんが、他の人が使用するライブラリを作成する場合、私にはもう少し重要に思えます。

あなたの意見は何ですか？公開するのに適した API は何ですか?

4

2 に答える 2

0

これら2つの選択肢の中で、下位互換性が問題にならない限り、私は＃1を好みます。図書館の利用者にパラメータを認識させ、提出するかどうかを賢明に判断させるのは良いことだと思います。

これを行う別の方法は、よりきめ細かい制御のためのコンテキストオブジェクトを用意することです。generalParametersをデータ構造として扱うのではなく、コンテキストのプロパティとして扱います。

class PostOperations {
  public void getPosts() {
    return getPostContext().getPosts();
  }

  public void getPostContext() {
    return new PostContext();
  }
}

class PostContext {
  public void setGeneralProperty1() {...}
  public void setGeneralProperty2() {...}
  public void getPosts() {...}
}

さまざまなget*Postメソッドをモデル化する方法を決定できます。システムでの意味に応じて、PostContextにこれらすべてのメソッドを持たせることも、getPosts（）の動作に影響を与えるPostContextの状態を持たせることも（例PostContext.setUserOnly(true)）、クラス階層を使用してモデル化することもできます（例class UserPostContext extends PostContext） 。

于 2012-08-24T17:08:04.227 に答える
0

私はこのようなことをします：

public void handle(some parameters) {
    //handle params
}
public void handle() {
    handle(null, null, -1, w/e);
}

あなたの編集ごとに：

このコードでは、オプション 2 を使用しています。何も取り込まずに null を渡す別のオーバーロードされたメソッドを追加した場合、null 値を渡す必要はありません。

于 2012-08-24T16:19:10.067 に答える