如果没有no-args构造函数的类，应如何扩展Number？

Question

我已经实现了一些扩展抽象java.lang.Number类的Java类。我没有立即需要序列化这些类的对象。但是，我确实想为这些代表“数字”的类提供其余的数字合约。麻烦的是java.lang.Number实现了Serializable。因此，我的类应该提供公共默认（即无参数）构造函数 - 我的IDE抱怨，但编译器仍将编译我的类。很好，但为“不可变”对象提供公共默认构造函数需要在由于序列化以外的任何原因调用构造函数时提供默认值 - 忽略这些类从静态工厂方法返回对象并且现在不公开任何公共构造函数。好吧，在许多情况下，零是一个很好的默认值，但是自然数 - 即正整数 - 在其域中不包括零，并且没有任何单个数字比任何其他数字更“特殊”......好吧......“一个“总是”特别“......

等，等等......

我确实研究过BigDecimal如何处理Number和Serializable，以确定解决这个问题的“正确”方法。但是，我已经能够检查的JavaDoc和源代码都显示，尽管扩展了Number，但BigDecimal并没有提供“no-args”构造函数。意识到：

  

仅仅因为Sun Microsystems / Oracle以这种方式实现它并不能使其“正确”。

我回到基本问题：

扩展java.lang.Number的“正确”方法是什么？如果提供“no-args”构造函数只是遵循规则的另一个Java约定：

  

这不是法律，只是个好主意......

通过忽略“惯例”来避免疣是最好的答案吗？如果是这样，我怎样才能满足IDE - 特别是Intellij--以及任何Java-to-other-language-or-environment翻译器，当Serializable引起其丑陋的头脑时，它可能会比Java编译器更严格？< / p>

Answer 1

嗯，总有很好的'NaN' - 不是一个数字。如果你可以代表它，那就是。

Answer 2

我的观点是，人们可能忘记在looking at the benchmarks之后与Java的内置序列化兼容。它比文本杰克逊慢8倍，似乎刚刚过时。

Answer 3

您也可以使空构造函数受到保护，这样序列化仍然有效。 Sun为BigDecimal所做的是提供readObject和writeObject方法，有关详细信息，请参阅here。