library api design:多个方法的额外参数

时间:2012-08-24 16:16:05

标签: java api oop

我正在为现有的REST API编写Java API库。

REST API有一些postOperations(getPosts,getUserPosts,getGlobalPosts等) 所以我有一个postOperations类暴露了它。 现在我需要向所有操作添加添加一组参数的选项(generalParameters)。

您认为更好的解决方案是什么?

  1. 向当前函数添加一个参数,这意味着有时用户必须传递null(实际上是80%的时间)。
  2. 为每个获取2个参数的操作添加一个重载函数(这意味着向该类添加6-7个重载方法)
  3. 我知道两种方式都有效。 在大多数应用程序中它并不是一个主要问题,但在编写库时,其他人会使用它对我来说似乎更重要。

    你有什么看法?什么是更好的api暴露?

2 个答案:

答案 0 :(得分:0)

我会做这样的事情:

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

根据你的编辑:

此代码使用选项2;如果你添加另一个不带任何东西的重载方法,但是为它们传递null,它们永远不会传递空值

答案 1 :(得分:0)

在这两个选项之间,我更喜欢#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拥有所有这些方法,或者您可以在PostContext上有一个影响其getPosts()行为的状态(例如PostContext.setUserOnly(true)),或者您可以使用类层次结构(例如class UserPostContext extends PostContext