JavaFX为何采用“静态构造器”？

在JavaFX里，像Font、Color这类类同时提供构造器和静态创建方法（比如Font.font()、Color.color()），可不是冗余设计，实际好处不少：

静态构造器的核心价值 #

• 可读性拉满，语义更清晰：静态方法的名字和类名呼应，比如Font.font()一看就知道是创建Font实例，比new Font()更直白。要是有多种创建逻辑，还能给静态方法起不同名字区分——比如Color.rgb()、Color.hsl()，一眼就能看出是用哪种颜色模式创建，比靠参数列表猜构造器重载强太多。
• 轻松实现实例缓存：静态方法内部可以偷偷搞缓存，比如常用的Color.RED、系统默认字体，不用每次调用都新建对象，省内存还提性能。但构造器不行，只要你new，就必须生成新实例，根本没法控制复用。
• 返回子类实例更灵活：静态方法可以返回父类的子类对象，调用者完全不用关心具体实现。比如Color.color()可能根据参数返回RGB或HSL的具体子类，但你拿到的还是Color类型，后续修改实现也不影响调用代码，符合开闭原则。而构造器只能返回当前类的实例，没这种操作空间。
• 参数校验与异常处理更灵活：构造器没法返回null，而且异常只能在构造过程中抛。但静态方法可以先校验参数，比如传入的字体名不存在时，能返回null或者抛出更明确的异常，处理逻辑更自由。

为什么不只用重载构造器？ #

• 参数歧义问题没法解：如果构造器重载的参数列表容易混淆，比如Font(double size)和Font(String name)，调用new Font("12")就会把字符串当成字体名还是转成double？编译器直接懵。但静态方法Font.font(12)和Font.font("Arial")完全没歧义。
• 做不到实例复用：刚才说过，构造器每次new都必须造新对象，对于频繁使用的实例，会造成不必要的内存浪费，静态方法的缓存优势是构造器没法比的。
• 语义表达能力太弱：构造器名字只能是类名，没法通过名字体现创建逻辑的差异。比如创建RGB和HSL颜色，用构造器重载的话，只能靠参数个数、类型区分，可读性极差，远不如Color.rgb()、Color.hsl()直观。
• 扩展性差：后续要加新的创建逻辑，静态方法直接加新方法就行，不影响原有代码。但加构造器重载的话，很可能和已有重载冲突，或者让旧代码自动匹配到错误的构造器，引发兼容性问题。

内容的提问来源于stack exchange，提问作者HLR