Qraizer: Вообще-то в понятии фабричного метода, как и понятии фабрики, обычно подразумевается, что он занимается инициализацией создаваемого экземпляра. Пока объект не создан, его нет, на его месте куча мусора. Не даром же у нас этим занимаются конструкторы – специальные методы класса, от которых зависит наполнение кучи мусора на месте атрибутов объекта его полноценными инвариантами. Так что создание подразумевает инициализацию в том числе. Выходит, что первый вариант априори несостоятелен, если рассматривать его с позиции корректности реализации парадигмы фабричного метода.
Другое дело, что конструкторы не зря умеют перегружаться, т.к. архитектура класса может предусматривать для инициализации, вообще говоря, несколько разных способов задавать эти инварианты. Но это и привносит неудобство в том смысле, что фабрикам приходится как-то с этой неоднозначностью разбираться. ИМХО наиболее простой, хоть и далеко не изящный, вариант – это предусмотреть в фабричном методе все те действия, которые иначе делали бы перегруженные конструкторы, и имитировать перегрузку конструкторов перегрузкой фабричного метода и/или простыми if()/switch()-ами.
Более изящный, но и посложнее, вариант. Методы классов, которые фабричному методу, возможно, понадобятся для инициализации, сделать приватными, и пусть он занимается инвариантами посредством них (вместо того, чтобы явно стучаться к полям объекта), и при этом сам фабричный метод должен быть другом создаваемых им классов. Идеально, если интерфейс инициализации может быть определён в базовом классе и для всех производных останется неизменным. Это позволит объявить фабричный метод другом только одному, базовому, классу и не заморачиваться приватными методами инициализации в производных.

https://forum.sources.ru/index.php?showtopic=419313&view=findpost&p=3835731