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:

  1. 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.
  2. 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.
  3. 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.

Comments (6)

  1. return42 says:

    I understanding in classifying programmers into one camp or another you have to make some gross generalizations, but I think you missed an entire classification of programmers, which imho, would encompass the majority.

    The coder that makes use of intellisense to determine which method to call ( and frankly, I think that’s most programmers… ) doesn’t mean that programmer has a narrow code focus. In reality, it could be quite the opposite.

    This programmer could just as simply be figuring out an implementation specific detail. Frankly, in a very well designed system, which method a developer uses to implement that system should be relatively unimportant. The design tells them what functionality the component needs going in and going out. So long as both contracts are fulfilled, there is no reason for the implementation itself to have been preconceived to this level of granularity.

    I think the reality of the situation is the majority of programmers are middle ground between what you have described. Your comment could have been completely reversed for non-optimistic programmers to something like this. (Yes, and I note the bias I’ve added… its for effect and doesn’t necessarily reflect my opinion on the matter )

    1. These programmers tend to focus on engineering and abstracting interfaces, often way past any productive point.

    2. In many cases these programmers have a wide focus, but have difficulty actually implementing code… at least within an efficient time frame.

    3. These programmers have a very architecture oriented perspective. However they get so caught up in engineering the product for reusability, to implement the newest methodology or optimizing performance that they can’t focus on the most important thing. Actually creating the product!

    Sadly some programmers are as you described and some even more sadly are as I just described. The reality is, the vast majority ( hopefully ) fall into a category rather in the middle.

    However, I think trying to summarize why a given type of programmer does or doesn’t have difficulty with factory design patterns has nothing to do with being in one classification or another.



  2. Thanks for your comments Mike.

    My comment about using Intellisense was simply to demonstrate the way that opportunistic programmers tend to think about the code that they need to write, not to suggest that using Intellisense is a definition of an opportunistic programmer or of a programmer with a narrow code focus.

    When opportunistic programmers have a narrow code focus and design time tools indicate that expected members aren’t available on a type, the reaction of these programmers is different to other types of programmers.

    I firmly believe, based on the observations I’ve made in a number of different API usability studies, that the work styles embodied by the different types of developers go a long way to explaining why some design patterns work for some types of developers and don’t work for other types of developers.


  3. Steven Clarke has an excellent post about using factories in APIs. The post explains why some developers…

  4. Haacked says:

    What if you provided some way for API designers to add hints that Intellisense would display to the developer that would help discoverability of the factory pattern.

    See http://haacked.com/archive/2005/06/28/7346.aspx for an idea.