discussion at the bottom of the page)
I've recently had cause to look seriously at the FactoryPattern
, along with the AbstractFactory
. 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:
- Another one that's very controversial is this idea of FactoryPatterns. This is a very strong result, and everybody hates this result, every professional programmer I've given this lecture to says "No!, Wait! I LOVE factories!"
- ... (description elided) ...
- It's actually a fairly common pattern ...
His slide says:
- Lab study with expert Java programmers
- Five programming and debugging tasks
- Within subject and between subject measures
- When asked to design on "blank paper" no one designed a factory
- Time to develop using factories took 2.1 to 5.3 times longer compared to regular constructors (20:05 v 9:31, 7:10 v 1:20)
- All subjects had difficulties getting using factories in APIs
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):
- ... so you have to think about whether you want to make this trade-off of making it more difficult for your programmers, or not, and this is not a consideration that most API designers have ever made.
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.
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.
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.
- The above situation is the whole reason FactoryPattern exists at all. To use it for something else is an abuse of the pattern. --SamuelFalvo?
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?
- It depends on the problem, but generally speaking, I alternate between solutions-based and patterns-based engineering. What can I do to solve problem X? OK, now that I've devised that, how can I refactor this plan for maximum re-use of concepts? Knowledge of patterns can help in the refactoring process. --SamuelFalvo?
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?
- Patterns very often help guide me to what code I'll need in the future. While I don't actually write code except for what I need, it at least gives me a "road sign" telling me what is expected to come down the road later. --SamuelFalvo?
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