The Design Space for Object Creation

While preparing a session on (object-oriented) object creation for my Advanced Design and Programming course, I noticed that there are at least two major ways of looking at how to decide on how to create an object. The traditional way is a (still unwritten) pattern language that utilizes the classic Gang-of-Four object creational patterns (and then some) to guide the developer in designing the object creation process.

Fortunately, object creation has a neatly defined design space with clearly independent dimensions and hence lends itself well to a structured discussion. Without further ado, here are the dimensions of this design space as I see them:

  1. Delegation. Who gets to create the object? Options are: on-the-spot, this-object, separate-object
  2. Selection. How is the concrete class selected? Options are: on-the-spot, by-switch-case, by-subclassing, by-colocating, by-mapping
  3. Configuration. How is a class mapping configured? Options are: in-code, by-annotation, by-configuration-file
  4. Instantiation. How is the concrete class instantiated? Options are: in-code, by-class-object, by-prototype, by-function-object
  5. Initialization. How is the new object initialized? Options are: default, by-cloning, by-fixed-signature, by-key-value-pairs, in-second-step
  6. Building. How is the object structure built? Options are: default, by-cloning, by-building

Using this design space, a developer can tailor a solution to the specific design situation at hand. Which options are chosen from the table for which dimension typically follows from the desired flexibility. As always, simpler is better, unless it is too simple.

It is also worth noting that design patterns cover a subspace of the overall design space. For example, the Factory Method pattern uses this-object delegation, by-subclassing selection, says nothing about configuration, in-code instantiation, any initialization, and says nothing about building.

The following table shows the relationship between some well-known design patterns and the choices they codify.

I think a pattern language is still warranted for some design decisions, actually most design decisions, perhaps, if the design space is sparsely populated with viable options. This is not the case with object creation: The design dimensions are almost completely orthogonal, allowing for a pick-and-choose approach. There simply aren’t too many constraints that reduce the options in this design space.

Posted on


  1. Jan Laudenbach Avatar
    Jan Laudenbach

    Dear Prof. Dr. Riehle,
    thank you for this very interesting diagram. Although it is explaining a lot, I have problems to understand the different options. Are there more informations about this topic?
    Best regards
    Dr. Jan Laudenbach

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share the Joy

Share on LinkedIn

Share by email

Share on Twitter / X

Share on WhatsApp

Featured Startups

QDAcity makes qualitative research and qualitative data analysis fun and easy.
EDITIVE makes inter- and intra-company document collaboration more effective.

Featured Projects

Making free and open data easy, safe, and reliable to use
Bringing business intelligence to engineering management
Making open source in products easy, safe, and fun to use