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

Question

Есть хорошее обсуждение этого в общем случае .

Однако мне было интересно, почему класс Pattern использует статический метод compile для создания объекта, а не конструктора?

Мне кажется, что использовать конструктор более интуитивно понятно.

Answer 1

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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