Нужно ли нам когда-нибудь выбирать конструкторы над статическими методами factory? Если да, то когда?

Я читал Эффективную Java Джошуа Блоха, и до сих пор он действительно оправдывает свою репутацию. Самый первый элемент делает убедительный пример для статических factory методов над конструкторами . Настолько, что я начал подвергать сомнению справедливость старых добрых конструкторов:).

Преимущества/недостатки книги приведены ниже:

<сильные > Преимущества:

У них есть имена!

У нас есть общий контроль экземпляра (Singletons, производительность и т.д.).

Они могут возвращать подтип/интерфейс

Компилятор может предоставить вывод типа
Недостатки:

Частные классы не могут быть подклассы

Они не выделяются в документации как конструкторы

Первым недостатком может быть "Хорошая вещь" (как упоминается в книге). Второй, я думаю, является лишь незначительным недостатком и может быть легко разрешен с помощью предстоящих выпусков java (аннотации для javadoc и т.д.).

Похоже, что в конце factory методы имеют почти все преимущества конструкторов, гораздо больше преимуществ и никаких реальных недостатков!

Итак, мой вопрос в основном состоит из трех частей:

Хорошо ли всегда использовать статические методы factory по умолчанию над конструкторами?
Всегда ли оправданно использовать конструкторы?
Почему объектно-ориентированные языки не поддерживают языковые уровни для фабрик?

Примечание. Есть два похожих вопроса: Когда использовать конструктор и когда использовать метод getInstance() (статические методы factory)? и Создание объектов: конструкторы или статические методы factory. Однако ответы либо просто содержат приведенный выше список, либо повторяют обоснование статических методов factory, о которых я уже знаю.

Ответ 1

статические заводы по-прежнему должны вызвать конструктор в конце. Вы можете переместить большую часть функциональности в статический factory, но вы не можете избежать использования конструктора.

С другой стороны, для простых случаев вы можете иметь только конструктор без статического factory.

Конструкторы - единственный способ установить конечные поля, которые IMHO предпочтительнее для нефинализированных полей.

Вы можете использовать конструкторы в подклассах. Вы не можете использовать статические фабрики для подкласса.

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

Ответ 2

Мне нравится комментарий из одного из похожих вопросов, которые вы выделили:

(Как решить, следует ли вам рекомендовать метод factory над конструктором),

"вам нужно решить, что вы пытаетесь выполнить. Или вы не хотите, чтобы люди вызывали ваш конструктор (вы создаете синглтон или factory), или вы не возражаете (как в NumberFormat выше, где они инициализируют некоторые объекты для удобства вызывающего абонента)"

Для меня это означает, что оправданно использовать конструктор, где метод factory не требуется. Без какой-либо необходимости в factory он просто делает код более сложным ( "какой именно подкласс возвращается сюда?" )

Ответ 3

Я очень хорошо согласен с Джошем Блохом здесь, и он делает это лучше, чем мог, но вот несколько мест, где статические фабрики не подходят:

Когда инъекция зависимости более разумна; Системы DI (конечно, Guice) склонны вводить вещи через своих конструкторов. В частности, DI подходит, если вы ожидаете, что параметры конструктора могут измениться в будущем.
Когда вы специально предназначаете для людей писать подклассы, и вы предоставляете скелет для их реализации.

Ответ 4

Конструкторы скучны, вы точно знаете, где их искать, вы знаете их объем, они как бы предсказуемы. Они там, чтобы построить сам объект, а не делать богоподобные задания. Если вы делаете слишком много других вещей, которые не имеют большого отношения к построению объекта, который, как вы знаете, вы делаете что-то неправильно. И невозможно "исцелить" это просто переименованием метода. Поэтому они, как правило, более целенаправленны, "лучше" по качеству кода, если у вас нет топ-оф-лайн разработчиков. (Когда у вас есть последнее, пункты, о которых я говорил, не имеют значения.)

Скучный материал. Позвольте сделать что-то более увлекательное и интеллектуальное...

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