Почему класс Java Pattern использует фабричный метод, а не конструктор?

Класс Pattern новее, чем многие вещи в JDK. Таким образом, я считаю, что они приняли более современный подход к использованию фабричных методов, а не старый подход публичных конструкторов. На самом деле вы не можете модифицировать фабричные методы для существующих классов.

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

Зачем вам два Pattern экземпляра одного и того же регулярного выражения? Статический метод создания позволяет реализациям потенциально кэшировать Patterns, иногда возвращающие один и тот же объект, если одно и то же регулярное выражение запрашивается несколько раз. Компиляция Patterns может быть дорогостоящей. Кроме того, если возникнут дополнительные compile методы (скажем, с другим синтаксисом), им можно будет дать разные имена вместо сбивающего с толку перегруженного набора конструкторов.

Шаблон статической фабрики используется, когда есть большая вероятность того, что базовая реализация может быть изменена таким образом, чтобы это могло повлиять на конструктор. Короче говоря, factory обеспечивает значительную гибкость для сопровождающего библиотеки, не будучи привязанным к совместимости двоичного кода и исходного кода на стороне построения.

Подробнее см. http://en.wikipedia.org/wiki/Factory_method_pattern, особенно "Другое раздел преимуществ и вариантов.

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