在Java中加倍约束?

时间:2012-02-08 13:44:42

标签: java

我正在将遗留的Python系统移植到Java。我主要是python开发人员,因此这个问题涉及我如何在原始Python系统中采用不令人满意的模式,但在我的Java版本中做得更好。

我正在研究的系统处理产品价格。所有产品的价格均为> 0.0。

在原始系统中,所有价格都表示为Python浮动对象(大致类似于Java Double)。以这些价格运作的函数通常以一堆断言开始,以检查价格的范围是否合理。由于存在许多函数,因此有很多断言在一段时间后变得非常重复。

这些断言总比没有好,但是当事情试图创造负价时,抛出错误要好得多,因为这就是错误所在。

在我看来,通过发明一种新的数字式东西,我可能会在我的重新实现中做得更好,它在所有方面都与Double完全相同,只是它不能用负值构造。如果我有这样的对象,那么我可以依赖Java的类型系统而不需要编写这么多的断言。

除此之外(开始)它将遵守所有正常的arethmatic规则 - 它将是Double的子类。

稍后,我可以通过添加包含更多现实世界资金功能的功能来扩展此课程,例如:防止几分钱。在我的初始版本中实际上并不需要这样做,但我希望在接下来的几个月里我采用任何模式来适应这种开发。

这种模式是否被Java开发人员接受?有没有更好的方法来保持具有类似数字的对象的灵活性,但却限制了它们的可能值?

4 个答案:

答案 0 :(得分:4)

嗯,首先,由于不精确,没有真正用钱处理钱的软件会使用浮点数学。持有整数个便士的“货币”类是解决这个问题的常用方法。

其次,是的,有一个构造函数通过抛出异常拒绝负数对于这样的类来说是一件好事。

Here's一篇关于该主题的Dobb博士期刊文章,附有代码。

答案 1 :(得分:1)

这是一个合理的想法(除了使用Double)。你不能扩展Double,因为它是最后一堂课。无论如何,你应该使用BigDecimal而不是Double(如OP评论中提到的@Jagger)。但是,您可能最好创建自己的Price类并在内部维护BigDecimal,因为这样可以更好地控制值的使用方式。

答案 2 :(得分:1)

是的,这确实不仅可以接受,而且是Java开发人员首先要做的事情。 除了一个例外:不要使用FLOATS或双手来支付货币价值

我建议:

  • 您使用所有要实现的方法创建一个接口。
  • 也许是一个抽象基类,它不是BigDecimal的子类,而是使用BigDecimal的私有值(没有子类化,但是委托模式)
  • 你创建了最终的类,实现了所有的金钱功能,断言和保护措施。

答案 3 :(得分:1)

首先,是的,继承某事或为此编写一个类是可以接受的,并且有人这样做,但是你不能继承java.lang.Double,它是{ {1}}课程。抛出构造函数远不及他们使用C ++或其他东西的灾难。

其次,你不应该把它存放在final中,除非你真的需要几分钱,你刚才说你没有。整数类是一个更好的主意。

第三,我建议继承double以获得自动装箱的所有好处。