Factory Pattern Considered Harmful

DocumentMode: (ThreadMode discussion at the bottom of the page)

I've recently had cause to look seriously at the FactoryPattern, FactoryMethod and FactoryMethodPattern, along with the AbstractFactory and AbstractFactoryPattern. I've always been a little concerned by it, because although people I respect claim that it's a genuine abstraction of a repeated pattern, and hence a useful refactoring, I've always found it to be difficult to use, difficult to grok, difficult to anticipate, and bug-prone.

I thought it might just be me, but I've been watching this video:

This video is talking about studies made of the productivity and errors of both novice and experienced programmers, and how we can develop tools that reflect the way they think. By studying the processes that programmers go through, the researchers hope to tailor the tools better to match the way programmers are inclined to approach tasks. Certainly some of the tools described earlier in the video look really, really good.

At about 45:50, shortly after talking about required constructors, he talks about the FactoryPattern, and he says this:

His slide says:

He observes that there are often other patterns to achieve the same advantages allegedly offered by the FactoryPattern, but which don't have the same problems. He doesn't say what they are. His conclusion (for this bit): You may not agree with his opinions, and you may question the methodologies and conclusions drawn from the studies, but he is reporting real studies done on real programmers.

So maybe it's not just me. Maybe the FactoryPattern is in some sense the wrong abstraction.

Were the expert Java programmers familiar with patterns? If not, that could explain why using a pattern was not their first thought, and why it was harder. --PeteHardie

I don't think that was specified, but the presentation does quote a figure of 60ish usages of factories in the java api so one would imagine an expert would know of a couple at least.

ThreadMode:

I've not yet watched the video, so can't (yet) comment in light of it, but I've certainly found FactoryPattern useful when dealing with varying run-time requirements -- such as handling running on either an interactive GUI or a headless server, or creating instances based on the contents of a user-defined configuration file or other user input. I'd be curious to know what alternatives are recommended, other than (obviously) not using a factory when you don't need one, or peppering your code with case statements.

However, this perhaps raises a broader issue: When programming, is it easier to think in terms of patterns, or is it easier to think in terms of the solution to the problem at hand, whatever it might be, regardless of patterns?

Patterns certainly provide a useful language for communicating with others (and oneself) about the code afterward -- e.g., "I used FactoryPattern to solve <x> and CommandPattern to implement <y>" -- but I don't find them particularly helpful when designing a solution. I don't think "what pattern do I need here?" I think, "what code do I need here?" Maybe that's just me, and perhaps I don't have a clear insight into my own pattern-informed thinking. Maybe it isn't normally a clear-cut dichotomy for experienced developers. But what about those with less experience?

I question the value of teaching patterns to beginning or even intermediate OO programmers, who are often still having difficulty grasping basic or advanced programming (and OO) concepts, let alone the high-level abstractions that patterns represent. It's like teaching advanced building architecture to carpentry students who are still learning about nails, screws, joists, beams, foundations and roofs. My experience has been that a few of the more advanced students do appreciate patterns, but for most it only confuses the issue. Once students have some large projects under their belt and start to discover the patterns emerging (and repeating) in their work, then the entire concept makes much more visceral sense. But, again, they appear to use patterns more as a language for communicating after coding than a source of inspiration or direction prior to coding. -- DaveVoorhis

It's an interesting video, but I think the fundamental thesis is flawed. The goal seems to be the development of tools and patterns that are better aligned with a 'natural' way of thinking, which, as suggested throughout the presentation, would result in higher productivity for both experts and novices. However this ignores the possibility that our so-called natural way of thinking is influenced by a whole range of experiences in our lives (indeed it may be worse than the mode of thinking programming forces us into). Perhaps the solution lies in teaching kids programming at a younger age... Back on topic, I think the lab study says more about the deficiencies in the language than the pattern (note that I am a JavaFan? so I say this with love). In particular, why not NewConsideredHarmful? I imagine most of us are comfortable not knowing when objects are reclaimed, why should we care when they are allocated. -- RichardCordova

CategoryPatternFactory

EditText of this page (last edited August 14, 2008) or FindPage with title or text search