这确实适合Flyweight。基本上，这就是您要使用静态函数完成的工作。关于如何为Flyweight对象提供服务，以免创建数千个对象，这里有一些想法。
一个是工厂，尽管您没有说明原因（因此其他任何想法可能会遇到相同的问题），但您却说过您曾考虑过并拒绝了它，因此我将不再赘述。
另一个是让值类型具有一种可以为其转换器服务的方法。像这样：
public class ValueType { public static final TextTransformable<ValueType> ConVERT = .... }然后像这样使用它：
ValueType value = ValueType.CONVERT.fromText(text); String text = ValueType.CONVERT.toText(value);
现在，这并不能强制所有ValueType都通过相同的机制提供其转换器，因为我认为您需要某种工厂。
编辑：我想我不知道您发现关于工厂的欠佳之处，但是我认为您专注于呼叫者，所以您的感觉如何：
ValueType value = getTransformer(ValueType.class).fromText(text);
可以通过静态导入工厂和具有如下签名的方法来完成上述操作：
public static <T> TextTransformable<T> getTransformer(Class<T> type) { ... }找到合适的转换器的代码不一定是最漂亮的，但是从调用者的角度来看，一切都很好。
编辑2：进一步考虑这一点，我看到的是您想控制对象的构造。你真的不能那样做。换句话说，在Java中，您不能强制实施者使用或不使用工厂来创建其对象。他们总是可以公开一个公共构造函数。我认为您的问题是您对执行构造的机制不满意。如果这种理解是正确的，则可以使用以下模式。
您只能使用私有构造函数创建一个包装您的值类型的对象。该对象可能具有通用类型参数，以了解其包装的值类型。该对象使用静态工厂方法实例化，该方法采用工厂接口来创建“真实”值对象。所有使用该对象的框架代码都仅将此对象作为参数。它不直接接受值类型，并且没有该值类型的工厂就无法实例化该对象。
这种方法的问题在于它的局限性。创建对象（工厂接口支持的对象）只有一种方法，并且使用值对象的能力有限，因为处理这些文本元素的代码仅通过该对象具有有限的交互。
我猜他们说没有一个软件问题无法通过额外的间接层解决，但这可能是一座遥不可及的桥梁。至少是值得深思的。
