代码之家 › 专栏 › 技术社区 › Pindatjuh

在API设计中避免使用原语?

primitive api java

Pindatjuh · 技术社区 · 16 年前

我正在设计一个API。它将有许多相同的方法,但有不同的参数原语。

public void someMethod1(int x);
public void someMethod1(float x);
public void someMethod1(double x);
public void someMethod2(int x, int y);
...
public void someMethod3(int x, int y, int z);
...

由于原语的存在,我不得不大量复制和粘贴,我认为随着时间的推移,这是不可维护的。避免方法和构造函数中的原语是个好主意吗?例如,上述内容的替换将是:

public <T extends Number> void someMethod1(T x);
public <T extends Number> void someMethod2(T x, T y);
public <T extends Number> void someMethod3(T x, T y, T z);

编辑:

这有什么坏处?

4 回复 | 直到 16 年前

danben 16 年前

它将是可用的,因为在Java 1.5和以后的自动装箱/自动装箱。你可以通过 int 希望 Integer 或者反之亦然,铸造将自动进行。同样适用于返回值。

请记住,在方法的主体中,您对参数的了解将比它们是某种形式的 Number . 只有当您不想区分整数表示和浮点表示时,这才适用。

它不会提高你的表现-对演员会有一些小的惩罚,但你不应该担心,直到你发现你有一个瓶颈。对于大多数应用,差异将是微不足道的。

是否使用 List 而不是数组应该由您的设计来决定,但是通常建议使用 表 除非需要数组。 表 S趋向于更灵活,不需要调整大小,具有 Collections API等。

brabster 16 年前

回答你关于 List<T> 与 T[] ,两者都公开了有关实现的详细信息。

列表& T; 可维护性比 t[] 因为您可以在不更改客户端代码的情况下更改列表实现。

如果客户机代码不应该修改列表, Iterable<T> 更好的方法是,您不公开任何关于实现细节的信息,并且防止除迭代之外的操作。

brabster 16 年前

API是关于语义的,所以我认为问题的答案如前所述(我应该在API设计中避免使用原语)是它取决于您的API所做的工作。

int addOne(int integer) 在语义上是一致的,不会在维护方面出现很多问题,因为它反映了问题域。

Employee getEmployee(int empID) 可能会被归类为不适当的,如果您的员工ID更改为字符串,则会出现维护问题。

Chris Dennett 16 年前

这是一个有效的模式,有时用于在模型视图控制器系统中定义属性。另外,如果在128到127的范围内使用int,则如果使用转换,它们将被Java自动缓存。 Integer.valueOf(int) 这可以加快一点 Integer 创造。还可以使用属性增加缓存范围 java.lang.Integer.IntegerCache.high 它总是至少是127。自动装箱也可能会使用这个整数缓存,但我不确定。如果您的类是为在高性能环境中使用而设计的,那么我将考虑其他替代方法并使用原语。