Должны ли мы когда-либо предпочитать конструкторы статическим фабричным методам? Если да, то когда?

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

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

Преимущества:

1. У них есть имена!
2. У нас есть полный контроль экземпляров (одиночки, производительность и т. д.)
3. Они могут возвращать подтип/интерфейс
4. Компилятор может обеспечить вывод типа

Недостатки:

1. Частные классы не могут быть подклассами
2. Они не выделяются в документации, как это делают конструкторы.

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

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

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

1. Является ли хорошей практикой всегда использовать статические фабричные методы по умолчанию вместо конструкторов?
2. Оправданно ли использование конструкторов?
3. Почему объектно-ориентированные языки не поддерживают фабрики на уровне языка?

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