当一个类或接口充当它自己的工厂时，是否有选择工厂方法名称的约定/最佳实践？ 参数中的所有数据是否都用于构造对象？

如何解决当一个类或接口充当它自己的工厂时，是否有选择工厂方法名称的约定/最佳实践？ 参数中的所有数据是否都用于构造对象？

我的问题可能是 this more general one 的特例，但那里的答案不适用于我的情况（并说它取决于上下文）。

考虑这样一种情况，其中一个接口或一个类充当它们自己的工厂。例如，在 Java 8 中，接口 Stream 带有静态方法 of(...)，类 Optional 带有静态方法 of(...)。虽然我还没有使用 Java 9，但我已经看到接口 List、Set 和 Map 获得了静态工厂方法 of(...) 或 {{ 1}} 为后者。它们似乎都从作为参数传递的所有条目中创建了不可变对象。

对于我自己的类，我经常使用名称 ofEntries(...) 从类似的对象中创建一个新对象，但我还没有看到在其他地方使用这种命名。本来我很想使用from(otherObject)，如果另一个对象会成为新对象的成员，并且对otherObject的更改会影响新对象，而of(otherObject)，如果我只从构建时的另一个对象和对另一个对象的更改不会影响新对象。但是根据我一开始的例子，“of(...)”这个名字似乎是为创建不可变对象而保留的。
所以我的具体问题是：

1. 有没有人看到 from(otherObject) 在 JDK 包中被用作创建者方法/工厂方法，如果有，它的确切含义是什么？
2. 我如何最好地用创建者方法/工厂方法的名称来表达新对象将依赖于用于构造的相关对象的更改的情况与不依赖于此类更改的情况之间的区别?

顺便说一句，我关于使用 from(...) 和 from() 的想法源于这样一个事实，即在另一个方向（类或对象是另一个类的工厂，使用此类的实例作为信息用于创建）某些对象具有包含“of()”（例如to）的方法来创建新对象，而不依赖于旧对象的更改和“List#toArray()”（例如{{ 1}})，当新对象将依赖于旧对象的变化时。

编辑： 在写下这个问题后，我意识到我对“of”的预期用法与我提到的不变性用法并不矛盾。例如。在 as 的示例中，创建者方法 Arrays.asList(...) 的参数不是另一个 List（这将对应于我的预期用例），而是 { {1}}。不变性意味着所有这些对条目的引用都不能更改。但是对每个条目对象（不是它们的引用）的更改显然会影响新的 of(E... elements)（请参阅 java-docs 中的 here）。如果 List 有另一个创建者方法 List，那么保留对​​ List 的引用并在新列表中看到旧列表中的更改是合乎逻辑的。所以我想我已经解决了在这种情况下使用“of”的问题。如果人们同意，那么剩下的问题就是，“from”是否适用于不保留对原始对象的引用的情况。

解决方法

Datetime API 大量使用“from”，例如 Instant#from(TemporalAccessor)、LocalDate#from(TemporalAccessor)。有趣的是，那些类也使用“of”，如LocalDate#of(int,int)。

---

通过观察和比较不同的案例，IMO，from 和 of 的不同在于：

参数中的所有数据是否都用于构造对象？

"from" 在创建的对象从参数中提取数据时使用，其中 "of" 使用参数中的所有数据。

所以当我们有 A a = A.of(b) 时，通常意味着 b 可以从 a 推导出来，这对于 A a = A.from(b) 的情况是不可能的。