Factory design pattern and usability
Luke Church watched the API usability presentation and contacted me with a question about a point I made regarding the factory design pattern and usability.
One thing that I probably didn’t make clear in the presentation is that the difficulties with the factory design pattern are greatest for opportunistic programmers (or programmers working in an opportunistic style). There are three reasons why these programmers have difficulties with the factory design pattern:
These programmers like to learn by exploration and make heavy use of design time tools to tell them what they can do. A common work style is to create an instance of an object and then use intellisense on that instance to see what methods the type exposes, thus learning what that type is capable of.
In many cases these programmers have a narrow code focus but a broad task focus. What I mean by that is that when they are writing code they tend to concentrate on the particular line of code that they are writing. They tend not to focus on higher levels of code abstraction such as the method that the line of code is contained within, nor the class exposing the method or the application that defines the class. Thus solutions that require them to consider their code at higher levels of code abstraction (e.g., configuring some object in a constructor and using it in another method, using another type to create an instance of a desired type) will be more difficult to find. In terms of their broad task focus, this means that they tend not to break a task down into many multiple, fine grained steps. Instead they consider the steps required to accomplish the task at a fairly high level. If a task has a high work-step unit it’s unlikely that these developers will be able to discover all the steps required.
These programmers have a very domain centered perspective as opposed to an implementation centered perspective. Sometimes the factory pattern is used for implementation details. Perhaps using the factory will lead to better performance if the factory can control instance creation. However, these details are often not considered by these programmers since they focus on the domain, not the implementation.
For these same reasons, other types of programmers have fewer difficulties with the factory design pattern. The pragmatic programmers are similar to opportunistic programmers (certainly in terms of point 1 above) but the difference is that when they discover that the type they want to create does not expose a constructor they expand their code focus and narrow their task focus as well as start to consider reasons why the type does not expose a constructor. Thus they are likely to end up finding the factory that lets them create the instance of that type.
Systematic programmers approach the task differently and, having a much wider code focus to begin with will be more likely to assume or to learn that type instances are created by a factory before they get started writing code.