Are "factory methods" anti-pattern now?

Question

I consider Joshua Bloch's Effective Java the best book on the language that I read. However, I started to wonder about something

One of the things he suggested was to prefer public static factory methods instead of public constructors. He mentioned, among others, two advantages

• a factory method doesn't have to create a new instance each time, instead it can return cached instances
• a factory method can return any subtype of its return type providing more flexibility

But isn't that all a dependency injection (DI) concern?

It made total sense when I was only learning Java, but now I start to look at it differently. Managing instances, returning proxies, it's what DI frameworks like Spring or Dagger do. Should we really allow Bloch's "embedded DI" in our classes in addition to (let alone in place of) that framework-based DI?

Did "factory methods" become an anti-pattern, as singletons did (and for a similar reason -- we decided to delegate instance management to DI frameworks to provide a better separation of concerns)?

    // here, Dagger is all alone responsible for instance management
    @Provides
    @Singleton
    public MyClass myClass() {
        return new MyClass("My Class Instance", 42);
    }

    // here, instance management may be performed by both Dagger and the class itself
    @Provides
    @Singleton
    public MyClass myClass() {
        return MyClass.of("My Class Instance", 42);
    }

Answer 1

But isn't that all a DI concern?

No, it isn't. Raw DI simply means that an object receives its dependency as parameter, as opposed to constructing it internally. You inject dependency.

It is true that modern DI frameworks do a lot more. In fact these implement more patterns, including factory pattern. Except it is hidden behind fancy semantics. Those annotations are converted into factories behind the scene. Factories are there, except are hidden.

The same in fact applies to singletons. These are not anti pattern, and in fact @Singleton annotation tells the framework to treat it as singleton. So maybe you still can instantiate the class manually, but as long as you let the framework manage it, then you have a singleton. Note that the singleton pattern doesn't mandate how this single instance is constructed (that is very language specific anyway), only that a given class has single instance. That's all.

Also using a DI framework requires... a DI framework. Obviously. Maybe you don't want such overhead. Assuming your dependency tree is not insanely complicated, it is arguably easier to write simple factories. And often hundreds of times faster at runtime. Well, to be honest I don't know much about Java, from what I read it seems that Dagger has a decent performance since it constructs underlying factories at compile time instead of runtime. Still there must be some performance hit, such framework has to be conservative, e.g. always enforce thread safety, even if it is not needed. And if Dagger claims to be thread safe (which seems to be the case) then this has to be done at runtime. I'm sure of it, because thread safety is not detectable at compile time in general.

Regardless, it is coupling. Often unnecessary. Note that typically it is easy to wrap a factory with a DI framework (although as I already mentioned I don't know much about Java). But if you hard couple your code with concrete DI framework then you have a problem: what if I want to use it in a project that uses different DI framework? Or no DI framework at all? So if I was supposed to write a standalone lib then I would completely avoid using a DI framework in favour of factories. Even with complicated dependencies. And in fact in my 10+ years of experience I did exactly that and it worked fine.

Answer 2

Whether something is considered an anti-pattern often comes down to how a particular design is used. Dependency injection frameworks can provide factories. They are a factory in their own right. DI frameworks are also a kind of service locator, which is a known "anti-pattern." DI frameworks work great when dependencies are known at compile time, or application startup. DI frameworks cannot help you in situations like the user choosing an option from a list in the user interface, and then your code needs to initialize a polymorphic object based on the user selection. Factory methods or factory objects can fill this void.

I've found factory methods or factory objects to be suitable when I need to decide on a concrete type based on information that was not yet available at compile time or application startup. I think there is a distinction between when to use a static method versus a factory object, though. Static methods couple your code to the class that contains the static method. This tight coupling won't hurt anything unless the factory requires outside resources like a file system, database, or web service to do its work. Callers cannot be verified by unit tests, because those outside resources cannot be mocked. That's when factory objects become necessary, because they can be stubbed or mocked for testing purposes.

A factory object works well for use cases where a static factory method is necessary, but introduces too much coupling. You can define an interface for the factory, which you can configure at application startup using — you guessed it — a dependency injection framework. The other objects your factory requires can be injected into the factory at the time it is created, and before the factory gets injected into another object where use case specific information is combined with preconfigured dependencies to create a polymorphic object at runtime. That's a mouthful! And certainly not the ideal solution for all your object creation needs.

DI frameworks, static factory methods, and factory objects all have their use cases. A perfectly fine design pattern can quickly become an anti-pattern when used in an inappropriate situation. DI frameworks, builders, abstract factories, singletons — they are all tools in your tool belt. Use them when it makes sense. Use a different tool when it doesn't make sense. None of those tools completely replace the others. There is some overlap in how they are used. Sometimes one tool is more specialized than the others and works best in a limited number of use cases where other tools would work in a less elegant fashion.

One of the things he suggested was to prefer public static factory methods instead of public constructors.

Again, you can over apply anything. That statement is a broad generalization that I would be wary of. Remember that constructors are static methods that many languages require you to prefix with the new keyword. I answered a question recently about builders returning factories. It was a misapplication of two good patterns. If you read the comments below my answer, you will quickly discover the OP was writing code to dance around calling a constructor without needing any of the benefits that more complex object creational patterns provide.

You will need to understand the problems various design patterns solve to know when it is appropriate to apply them. Misapplying them is the anti-pattern.

---

There has been a lot of follow-up comments on answers to this question. Perhaps an illustration would help clear this up.

DI frameworks are the Swiss Army Knife of object creation. They work for a lot of scenarios. Factories and builders are more like a hammer. They are a more specialized tool. Please pardon the abuse of an old adage:

When all you have is a hammer, everything looks like a nail. But when you've become accustomed to your Swiss Army Knife always having a suitable tool, don't be afraid to reach for a hammer when you have a nail to pound.

Answer 3

This is how is going: constructor, factory, dependency injection where dependency injection uses factories that use constructors.

To address both questions dependency injection supports different scopes of the instances it "knows" including singleton scope.

Neither of the two are anti-patterns. My opinion. Probably it could be twisted in unbeknown ways the same way everything could be though that's not what design patterns and programming principles are about.

Answer 4

DI just for IO objects, why? Because you can change the implementation depending on the scope, integration test, new technology, etc. Everything else is likely okay to not have reference transparency,e.g domain objects like aggregators, domains services, etc. Unless you need it, then you apply specific pattern, like strategy.

Answer 5

The only anti-pattern here is the use of a DI framework, Spring Framework being the worst. Precisely because it leads to uncontrolled accidental complexity.

Typically developers' perception of how much more robust software without such frameworks can be, is based on the codebase they work with in a big corporation - the leap is too big from their daily reality to even imagine the possibility of not using Spring or whatever DI framework.