Design – Are Factories That Only Return One Type of Object Bad

designfactory

Someone in a Stackoverflow post (I didn't bookmark the question unfortunately) commented, that Factories that only return one type of object are a code smell.

I find myself writing these kinds of factories pretty often. Sometimes because i don't want to bloat my code with constructor overloads and sometimes because i just want to give a name to an object with specific attributes. A factory would then look like this:

class CarFactory {
    public static Car createDefault() { return new Car(0, 0, 0, 0, 0, Color.BLACK) }
    public static Car createFancy() { return new Car(1, 1, 1, 1, 1, Color.RAINBOW) }
    ...
}

This is just a general example, but i think the calls look much better in the code than the constructor calls with a load of ominous values.

However these kinds of factories usually don't do runtime decision making (like factory methods often do). And i probably won't create interfaces either (Like the Abstract Factory Pattern uses). It's just a class that provides static creation methods, so that my code doesn't get cluttered and i have only one method to change if i think, that a fancy car should be red with stripes.

Are these kinds of Factory Classes necessarily bad?

Best Answer

The purpose of the factory pattern is to provide an abstraction between object creation and code that needs to create objects. There are many reasons why this may be desirable:

  • Objects might be able to be pooled, and a factory can manage the pool. This is what Java's Integer.valueOf(int) does.

  • Objects might have tricky constructors to use. This is often a sign of an object doing too much, but sometimes that is just how an object needs to be. A factory can provide a single location to invoke the complex constructor.

  • Objects might have state that requires both a constructor call and post-construction initialization. While a bad thing, you might be backed up against a wall and forced to do that because of language or framework constraints. A factory allows you to ensure all creation logic goes through one chokepoint that can be tested and reused, ensuring all objects are created correctly.

None of this answers your question directly, however.

YAGNI is a really good mantra, but sometimes you know you will need it, and it is less effort to get it right the first time than to do extensive refactoring later. If I sketch out a design where I know there will be complex construction logic, I may go ahead and create a factory first so I do not need to perform tedious refactoring later. Even with an IDE, that can still require a lot of manual changes.

Factories that return a single object, inflexible factories, are testable. If you know you always get the right type of car from that factory, code that uses cars is easier to test as well. Maybe I have code that crashes cars together like a child playing with Hot Wheels. If there is a defect in my crash logic, is it because of the crash logic itself? Maybe it is constructing cars incorrectly? A factory like the one you mention might make it easier to identify defective code. If the car test is correct but the crash test fails, that tells me something different than both tests failing.

In the end this is a bit of a subjective question, but there are objective reasons for picking one way or the other (factory or direct instantiation). No, this is not necessarily a sign of bad code. Look at the design as a whole, and weigh the cost and benefit of both options in the context of your project.

Related Topic