我已经实现了一些扩展抽象 java.lang.Number 类的 Java 类。我不需要立即序列化这些类的对象。但是，我确实想为这些代表“数字”的类提供其余的数字契约(Contract)。问题是 java.lang.Number 实现了 Serialized。因此，我的类应该提供公共(public)默认(即无参数)构造函数——我的 IDE 提示，但编译器仍然会编译我的类。很好，但是为“不可变”对象提供公共(public)默认构造函数需要在出于序列化以外的任何原因调用构造函数时提供默认值 - 暂时忽略这些类从静态工厂方法返回对象并且现在不公开任何公共(public)构造函数。嗯，在很多情况下零是一个很好的默认值，但是自然数——即正整数——在它们的域中不包括零，并且没有一个数字比任何其他数字更“特殊”......好吧......“一个“总是“特别”......
等等等等......
我确实研究了 BigDecimal 如何处理 Number 和 Serialized，以确定解决这个问题的“正确”方法。然而，JavaDoc 和我能够检查的源代码都表明 BigDecimal 不提供“无参数”构造函数，尽管具有扩展的 Number。意识到:
Just because Sun Microsystems/Oracle implemented it that way doesn't make it "right."
我回到基本问题:
扩展 java.lang.Number 的“正确”方法是什么？如果提供“无参数”构造函数只是遵循规则的另一个 Java 约定:
It's not a law, just a good idea...
忽视“惯例”是避免问题的最佳答案吗？如果是这样，我如何才能满足 IDE(尤其是 Intellij)以及任何 Java 到其他语言或环境的翻译器的要求，当 Serialized 抬起它丑陋的头时，它们可能会选择比 Java 编译器更严格？/p>
最佳答案
嗯，总是有好的“NaN”——不是数字。如果你能代表它，那就是。
关于java - 对于没有无参数构造函数的类，应该如何扩展 Number？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20506291/