Question

我正在设计一个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);
...

由于原语，我必须复制＆amp;粘贴很多，我觉得随着时间的推移这是非常难以维护的。避免方法和构造函数中的原语是一个好主意吗？例如，上面的替换将是：

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

编辑：

这有什么缺点？

Answer 1

由于Java 1.5及更高版本中的自动装箱/自动装箱，它将可用。您可以将int传递给期望Integer的内容，反之亦然，并且演员会自动发生。这同样适用于返回值。

请记住，在你方法的主体中，你对自己的论点知之甚少，而不是Number的某种形式。只有在不想区分整数和浮点表示时，这才适用。

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

是否使用List而不是数组应该由您的设计决定，但除非必须使用数组，否则通常建议使用List。 List往往更灵活，不需要调整大小，具有Collections API的所有好处等。

Answer 2

要回答有关List<T>与T[]的问题，请同时公开有关实施的详细信息。

List<T>比T[]更易于维护，因为您可以在不更改客户端代码的情况下更改List实现。

如果客户端代码不应修改列表，Iterable<T>会更好，因为您不会公开任何有关实现细节的信息并阻止迭代以外的操作。

Answer 3

API是关于语义的，所以我认为所述问题的答案（我应该避免API设计中的原语）是它取决于你的API做什么。

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

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

Answer 4

这是一种有效的模式，有时用于在模型 - 视图 - 控制器系统中定义属性。此外，如果您使用-128到127范围内的整数，如果您使用Integer.valueOf(int)进行转换，它们将由Java自动缓存，这可以加快Integer创建的速度。您还可以使用始终至少为127的属性java.lang.Integer.IntegerCache.high来增加缓存范围。也可能是自动装箱也会使用此整数缓存，但我不确定。如果您的课程设计用于高性能环境，我会考虑其他替代方案并使用原语。

避免API设计中的原语？

4 个答案: