Почему нет открытых конструкторов в классах Java и Pattern и Matcher?

Question

Мне хотелось бы знать, есть ли какая-то конкретная причина, по которой в Java-классе Pattern and Matcher нет открытого конструктора?

Спасибо

Answer 1

Многие фреймворки избегают использования прямых конструкторов для сложных объектов, предпочитая вместо этого более элегантные фабрики.

Шаблон генерируется путем «компиляции» регулярного выражения, поэтому вы делаете статический вызов метода «compile». Инициализирует все, что нужно. Сопоставление является специфическим для шаблона и, следовательно, генерируется объектом шаблона, а не непосредственно пользователем.

Если бы у сопоставителя был конструктор, который принял шаблон, то у конструктора сопоставителя мог бы быть доступ к закрытым полям объекта шаблона.

Другое потенциальное преимущество этого подхода (по сравнению с прямым построением) состоит в том, что в принципе возможно прозрачно предоставлять различные механизмы согласования для пользователя, создавая различные подтипы Pattern и Matcher за кулисами. Например, предположим, что у вас были разные реализации сопоставления для регулярных выражений, которые соответствуют строке фиксированной длины (например, без подстановочных знаков), и для регулярных выражений, которые содержат звездочку или плюс, и что была разница в производительности. Это, как говорится, не похоже, что это на самом деле имеет место, поскольку Matcher определен как конечный класс, хотя вполне вероятно, что внутреннее устройство тесно связано с шаблоном.

Answer 2

Я не смотрел на реализацию ни одного из классов, но я бы предположил, что Pattern.compile() является статическим, поэтому класс может кэшировать недавно скомпилированные шаблоны, вместо того, чтобы каждый раз создавать новый объект (т. Е. Весить).

Answer 3

Исходный код для compile () в java.util.regex.Pattern:

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

и

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

Это означает, что два статических метода вызывают приватный конструктор. Я не вижу в этом никакого реального преимущества, в отличие от простого обнародования самих конструкторов.

Единственный открытый способ создания Matcher - это использование объекта Pattern с помощью метода pattern.matcher(), который имеет смысл в том смысле, что Matcher существует только в контексте Pattern.

Answer 4

По моему мнению, причина этого больше связана с семантикой. Когда вы читаете Pattern.compile (), он передает тот факт, что ваш ввод будет проверен и преобразован во внутреннее представление, то же самое сообщение, вероятно, не передается при произнесении new Pattern ().

На шаблонах и фронтах регулярных выражений это может быть важно из-за длинной исторической тени, которую отбрасывает perl, сравнения с которой подробно документированы в документах API.

Answer 5

это статический (или окончательный) класс. все, что вам нужно, можно сделать с помощью методов compile () и matcher ().