I am working on a program to automatically design heater units based on varying client specifications. The process for creating each heater is quite involved and requires multiple optional steps depending on the type of the heater and it's options.

I am trying to figure out what the best way of creating heater objects is.

  • If I use a single constructor, it will most likely end up as a humongous mess of IF statements.
  • If I use subclasses, I will need hundreds to manage all the combinations.

Based on this, my understanding is that using the builder design pattern would make sense. I can just build the object step by step, adding the options as I go.

Two of the types of heaters (lets call them type A and B) we manufacture are conceptually similar enough that their concrete builders have the same interface.

The problem is that I have a third type of heater (type C) that shares most of the interface, but not all of it. Specifically the core of the heater is designed by a completely different set of steps that has no overlap with the other two types.

This leaves me unsure of how I should organize things.

  • I could generalize the design of all types enough to have a massive .build_core() method that applies to all concrete builders, but this doesn't really work since building the core isn't a single step (for all types).
  • I could create two independent builders, one for type A & B and a second incompatible one for type C, but this means repeating all the code that is compatible.
  • I could add the steps required for all types in all concrete builders, but this means they would have access to steps that are mutually exclusive.

Is there a way to handle this issue with a builder pattern? Is a builder even the right tool for the job?

  • 4
    You can combine objects without the builder pattern - that's not the problem either of the two builder patterns is solving. Break down your classes into object with narrow responsibilities, and then make them composable (see patterns like Composite, Strategy, Decorator, Template Method and the like). Jan 6 at 22:44
  • 1
    I think this is pretty hard to answer without knowing more details of your real code.
    – Doc Brown
    Jan 7 at 12:57

1 Answer 1


Without delving into details, since builder design pattern is a solution for object creation, an approach using builders can be a viable one with the straight forward implementation of one builder that sets values while a sequential read of client's specification.

The details of building only heaters of types that are manufactured add complexity that could be modelled using a monad implementation thus wrapping each possible value from heaters' specifications in a context enabling additional operations based on value's existence/non-existence in client's specifications, additionally beside setting values into the builder.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.