Java Design Patterns – Static Factory vs Singleton Factory

design-patternsfactory-methodjavasingleton

In some of my code, I have a static factory similar to this:

public class SomeFactory {

    // Static class
    private SomeFactory() {...}

    public static Foo createFoo() {...}

    public static Foo createFooerFoo() {...}
}

During a code review, it was proposed that this should be a singleton and injected. So, it should look like this:

public class SomeFactory {

    public SomeFactory() {}

    public Foo createFoo() {...}

    public Foo createFooerFoo() {...}
}

A few things to highlight:

  • Both factories are stateless.
  • The only difference between the methods are their scopes (instance vs static). The implementations are the same.
  • Foo is a bean that does not have an interface.

The arguments I had for going static was:

  • The class is stateless, therefore doesn't need to be instantiated
  • It seems more natural to be able to call a static method than to have to instantiate a factory

The arguments for the factory as a singleton was:

  • Its good to inject everything
  • Despite the statelessness of the factory, testing is easier with injection (easy to mock)
  • It should be mocked when testing the consumer

I have some serious issues with the singleton approach since it seems to suggest that no methods should ever be static. It also seems to suggest that utilities such as StringUtils should be wrapped and injected, which seems silly. Lastly, it implies that I'll need to mock the factory at some point, which doesn't seem right. I can't think of when I'd need to mock the factory.

What does the community think? While I don't like the singleton approach, I don't seem to have a terribly strong argument against it.

Best Answer

Why would you separate your factory from the object-type it creates?

public class Foo {

    // Private constructor
    private Foo(...) {...}

    public static Foo of(...) { return new Foo(...); }
}

This is what Joshua Bloch describes as his Item 1 on page 5 of his book, "Effective Java." Java is verbose enough without adding extra classes and singletons and whatnot. There are some instances where a separate factory class makes sense, but they are few and far between.

To paraphrase Joshua Bloch's Item 1, unlike constructors, static factory methods can:

  • Have names that can describe specific kinds of object creation (Bloch uses probablePrime(int, int, Random) as an example)
  • Return an existing object (think: flyweight)
  • Return a sub-type of the original class or an interface it implements
  • Reduce verbosity (of specifying type parameters - see Bloch for example)

Disadvantages:

  • Classes without a public or protected constructor cannot be subclassed (but you can use protected constructors and/or Item 16: favor composition over inheritence)
  • Static factory methods do not stand out from other static methods (use a standard name like of() or valueOf())

Really, you should take Bloch's book to your code reviewer and see if the two of you can agree to Bloch's style.

Related Topic