> A separate factory type means you have to write twice as much code for no real benefit.
Ah! There's the confusion. What I meant was I see factory methods in code we consume on a daily basis, not that we write the full factory objects. A number of Java projects have static factory methods that provide the interface implementation instance based on your configuration.
If you're actually using that configurability (i.e. your method actually instantiates different implementations in different cases) then no - that's the same thing you'd do in any language. If you're pre-emptively defining factory methods that actually just call the normal constructor then yes (a lot of Java bloat is like that - see also getters and setters on every field for the sake of the 0.01% where you actually want to do something other than just read/write the field).
Ah! There's the confusion. What I meant was I see factory methods in code we consume on a daily basis, not that we write the full factory objects. A number of Java projects have static factory methods that provide the interface implementation instance based on your configuration.
Would you still object to this kind of design?