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?