When should i use a factory method instead of a constructor?

[Mason16]

I’m trying to understand when it makes sense to use a factory method instead of just calling a constructor directly in my code. I keep reading that it helps with encapsulation, but in my current project, adding a separate method for object creation just feels like extra boilerplate without a clear benefit.

[Aria.S]

We added a small factory to construct User objects from a DTO. It came in handy when the creation path changed later—like swapping in a different parsing rule or adding a cache—so the rest of the code didn’t have to touch the details. Without that, I felt the constructor was getting too fat.

[Scarlett.A]

Most days I just call the constructor. Unless I need a different subclass or centralized validation, it feels like boilerplate to introduce a factory just for that.

[EthanS]

I tried using a factory when there were several shapes of the same interface and the consumer shouldn’t care which one it is. It helped in tests at first, but then you end up mocking the factory and that adds indirection.

[GeorgeDL]

Is the real issue the complexity of the constructor or the desire for a clean API, and are we solving the wrong problem by introducing a pattern just to hide what’s already in the class?