为什么java的模式和匹配器类中没有公共构造函数？

Question

我想知道java的Pattern和Matcher类中没有公共构造函数的具体原因是什么

谢谢

Answer 1

java中compile（）的源代码。util。正则表达式。模式是：

public static Pattern compile(String regex) {
    return new Pattern(regex, 0);
}

及

public static Pattern compile(String regex, int flags) {
    return new Pattern(regex, flags);
}

这意味着这两个静态方法正在调用私有构造函数。我看不出这有什么真正的好处，而不是简单地公开构造函数本身

创建匹配器的唯一公共方法是通过pattern.matcher()方法从模式对象创建匹配器，这很有意义，因为匹配器只存在于模式的上下文中

Answer 2

我没有研究这两个类的实现，但是我假设Pattern.compile()是静态的，因此该类可以缓存最近编译的模式，而不是每次实例化一个新对象（即flyweight）

Answer 3

在我看来，这样做的原因更多地与语义有关。当你们读模式的时候。compile（），它传达了这样一个事实，即您的输入将被验证并转换为内部表示形式，而在说new Pattern（）时可能不会传达相同的消息

在模式和正则表达式方面，这可能很重要，因为perl投射了很长的历史阴影，API文档中大量记录了与之的比较

Answer 4

许多框架避免对复杂对象使用直接构造函数，而更喜欢更优雅的工厂

模式是通过“编译”正则表达式生成的，因此可以对“编译”方法进行静态调用。它初始化了所有必要的东西。匹配器是特定于模式的，因此由模式对象生成，而不是由用户直接生成

如果匹配器有一个接受模式的构造函数，那么匹配器的构造函数可能必须访问模式对象的非公共字段

这种方法的另一个潜在优势（与直接构造相比）是，原则上可以通过在幕后实例化不同类型的模式和匹配器，向用户透明地提供不同的匹配引擎。例如，假设您对匹配固定长度字符串（例如，没有通配符）的正则表达式和包含星号或加号的正则表达式有不同的匹配器实现，并且存在性能差异。也就是说，这似乎并没有真正发生，因为Matcher被定义为最终类，尽管内部很可能与模式紧密绑定

Answer 5

它是一个静态（或最终）类。您需要的一切都可以通过compile（）和matcher（）方法完成