В этом случае хорошо обсуждается в general case.Почему класс Java Pattern использует метод factory, а не конструктор?
Однако, мне было интересно, почему класс Pattern использует статический метод compile для создания объекта, а не конструктора?
Кажется мне более интуитивно понятным использование конструктора.
Класс шаблонов новее, чем много вещей в JDK. Поэтому я считаю, что они использовали более современный подход к использованию заводских методов, а не более старый подход публичных конструкторов. Вы не можете модифицировать заводские методы для существующих классов.
Вообще говоря, нет оснований для использования конструктора по заводскому методу, поэтому я думаю, что это все, что было для него. Фабричные методы позволяют вам абстрактно создавать объекты, что может быть очень полезно.
Зачем вам два Pattern экземплярам этого же регулярного выражения? Статический метод создания позволяет реализациям потенциально кэшировать Pattern s, иногда возвращающий один и тот же объект, если одно и то же регулярное выражение задается несколько раз. Компиляция Pattern s может быть дорогостоящей. Также, если необходимы дополнительные методы compile (например, разные синтаксисы), им могут присваиваться разные имена, а не путано перегруженный набор конструкторов.
В общем, ваш аргумент верен. Думаю, такая оптимизация должна оставаться необязательной. Тем не менее, есть много других мест, где эта оптимизация могла бы быть применена. – ordnungswidrig
Использование фабричного метода для Pattern также может в конечном итоге разрешить использование реализации регулярного выражения сторонней плагины. К сожалению, Sun не реализовала никаких функций, которые вы могли бы получить при использовании заводского метода (возможность подключаемого модуля, кэширование).
Статический заводский шаблон используется, когда существует хорошая вероятность того, что базовая реализация может быть изменена таким образом, который может повлиять на конструктор. Короче говоря, завод допускает значительную гибкость для поддерживающего библиотеку без привязки к двоичной и исходной совместимости на стороне строительства.
Подробнее см. http://en.wikipedia.org/wiki/Factory_method_pattern - особенно раздел «Другие преимущества и варианты».
Для получения дополнительной информации см. Статью [Dr. Joshua Bloch] (https://en.wikipedia.org/wiki/Joshua_Bloch), выдержка из его книги * Эффективная Java * (2e): [* Создание и уничтожение объектов Java - Пункт 1: Рассмотрение статических заводских методов вместо конструкторов *) (https://www.informit.com/articles/article.aspx?p=1216151) –