为什么Number类没有像add()或negate()这样的方法？

Question

这是一个关于Java设计的问题。

为什么在add()类上没有像negate()和java.lang.Number这样的方法，但是在它的一些子类上呢？

我是说..。没有统一。我可以在+或-操作符上使用Float、Long和其他自动装箱类，也可以在BigDecimal或BigInteger上使用add()和negate() (这违反了SRP)。

因此，如果我们允许在Byte/Short/Integer/Long上进行这些操作(包括自动装箱和操作符)，那么为什么不只是在Number中添加一个abstract Number negate()等

这有什么原因吗？

Answer 1

最重要的是，保持向后兼容性。

您提到的这些方法不在java.lang.Number的第一个版本中，它们需要是抽象。为什么是抽象的？假设您在Number拥有negate()方法之前创建了自己的negate()子类，现在将negate()方法添加到Number中。如果negate()方法不是抽象的，那么在java.lang.Number中应该有一个通用的实现。它应该返回什么类型的对象？这是不可能的好决定。它应该是一个Double，像这样：public Number negate() { return new Double(this.doubleValue()); }吗？这会突然将您的ComplexNumber转换为否定的双倍。

添加抽象方法将无法工作，因为它会破坏现有的第三方Number子类，因此会破坏向后兼容性。

向后兼容性是许多看似明显的API改进现在无法实现的原因。

Answer 2

我想可能是因为以下原因。

Number也是AtomicInteger和AtomicLong的一个超类.如果Number有一个add()方法，那么这些子类也必须实现它，这在保持原子性的同时是不可能的。

相反，这两个类将addAndGet()实现为单个原子操作。

Answer 3

简而言之，这是因为您不知道从二进制操作返回什么类型。

当您添加两个相同类型的Number子类时，返回类型是毫无疑问的。但是，对两个不同类型的Number实现的操作会产生多个分派问题(也就是说，每个类都需要知道如何处理Number的所有其他子类)。

这将是困难的，但不是不可能的。不可能的是处理用户定义的Number子类。由于Number是一个接口，用户可以自由地创建自己的实现。排除它们太不一致；不可能包含它们，因为库设计人员无法了解它们。