扩展BigDecimal？

Question

我有相当多的代码在使用BigDecimal类，我讨厌这种笨拙的接口。

我用以下方法创建了一个带有静态方法的帮助器类，从而减轻了使用BigDecimal处理整数的痛苦：

compare(BigDecimal first, int second)
divide(BigDecimal dividend, BigDecimal divisor, int scale)
divide(BigDecimal dividend, int divisor, int scale)
divide(int divident, int divisor, int scale)
multiply(BigDecimal first, BigDecimal second, int scale)
multiply(BigDecimal first, int second, int scale)
multiply(int first, int second, int scale)
zeroPad(BigDecimal value, int totalLength, int scale)

这就是我现在所需要的，代码比以前更具可读性了。然而，我读到静态方法是一个“坏”的东西，它们不遵循面向对象的原则。

但是，如果我扩展BigDecimal，我将定义一个新的类型，因此我必须重新定义所有方法来将它们与我的对象包装在一起，否则我将无法将结果用于增强的方法。这似乎不是一件明智的事情。

你将如何处理这个问题？

Answer 1

我会完全按照你的方式去做！

这种类型的所有设计决策都必须基于这样一种愿望，即使代码更易维护，以供下一位将在您之后接管代码的程序员使用。这就是为什么我们首先进行面向对象设计和基于组件的开发。

但是考虑到Java的语法，很难为基于数学的表达式创建API。我对当前的BigInteger接口有两个问题：

对于像math-notation

• it

这样的对称运算符，它与通常的不对称不对称非常接近

运算符重载是C++的为数不多的特性之一，我在Java语言中忽略了这一点

哪一个更具可读性？

BigInteger a = ...;
BigInteger b = ...;
BigInteger c = divide(a, b);

或

BigInteger a = ...;
BigInteger b = ...;
BigInteger c = a.divide(b);

就个人而言，我更喜欢第二个版本。

更糟糕的情况是，不同基本类型的数量是同一表达式的一部分。例如。

int a = ...;
BigInteger b = ...;
BigInteger c = divide(a, b);

或

int a = ...;
BigInteger b = ...;
BigInteger c = BigInteger.valueOf(a).divide(b);

还要考虑符号之间的巨大差异，以及相应数学符号中的小变化：

将

• (a-b)*c转换为a.subtract(b).multiply(c)，或者将multiply(subtract(a,b),c)
• c*(a-b)转换为c.multiply(a.subtract(b))或multiply(c,subtract(a,b))

对我来说，编写和阅读静态方法表示法比“纯粹的”基于面向对象的表示法更容易。

Answer 2

不要扩展BigDecimal，在它周围使用一个包装类(就像你已经做的那样)或者像Commons Math这样的其他框架。

Dfp看起来很像你想要的-- org.apache.commons.math.dfp.Dfp

Answer 3

如果创建的类扩展了另一个类(例如，在本例中为BigDecimal )，则子类仍具有父(超级)类的所有属性。在您的示例中，如果您编写：

public class UsableBigDecimal extends BigDecimal {
...
}

任何UsableBigDecimal对象仍然是BigDecimal的实例，因为它是它们的超类。您可以像使用任何BigDecimal对象一样使用它们，包括静态实用程序方法。

也就是说，在我看来，在处理核心Java类时，静态实用程序方法作为共享公共代码的一种方式是完全可以接受的。