我最近刚遇到一个BigDecimal我以前没有意识到的行为.对于精度很重要的区域,我总是将它们用作双倍的替代方法.例如在财务计算中.
但是我最近遇到了这个事实
new BigDecimal("1.0").equals(new BigDecimal("1")) == false
我不得不承认我对此感到惊讶.我认为这是因为第一个的比例为1,而第二个的比例为0,但它似乎仍然是反直觉的.我认为之前我从未遇到过的原因是因为我们总是使用固定比例BigDecimals进行财务计算.
检查BigDecimal 文档我可以看到,这compareTo() == 0应该用于检查忽略比例的相等性,同时equals()比较值和比例.
当使用BigDecimal不同尺度的s 时,我应该注意其他类似的问题吗？
我注意到Java中的Set和SortedSet接口之间存在逻辑不一致.
如果在比较期间它们是相同的,则SortedSet将不同的对象(通过equal()方法)识别为equals,但它在逻辑上是不正确的.对象的比较应仅对对象的顺序负责.
例如:我可以有很多产品,我想按价格对它们进行排序.在这种情况下,SortedSet不能包含具有相同价格的不同产品:["salt",0.5 $],["milk",1 $],["bread",1 $],["bananas",2 $在上面的例子中,牛奶将被面包取代.在这种情况下,将违反继承的Set接口的合同,因为不相等的对象会相互替换.我是Reded JavaDoc的SortedSet,并且知道这个行为有很好的记录,但我认为这是一个逻辑上的失败.
你有什么看法,也许你已经和Set和SortedSet有类似的问题了？