in reply to Builder design pattern with lots of parameters - trying to declutter design

I'm no expert in object oriented programming, but I would think that for example the VehicleDealer class doesn't need any attributes belonging to a car or Motorbike. Instead it will delegate those details it gets as a parameter to the VehicleBuilder which in turn delegates to the CarBuilder. And the CarBuilder will at last call new with those parameters so that the attributes are set. Only the car class should have an attribute like outside color or inside color, while the Builders might have methods like paint or configure.

Check out the wikipedia example Builder_pattern. Note that only the actual pizza has an attribute dough. Ok, the builders have a method for every attribute. if you want to avoid this, one method would handle a group of connected attributes (i.e. if you specify outside color green, the method knows a default matching color for the inside).

  • Comment on Re: Builder design pattern with lots of parameters - trying to declutter design

Replies are listed 'Best First'.
Re^2: Builder design pattern with lots of parameters - trying to declutter design
by tospo (Hermit) on Mar 28, 2011 at 19:40 UTC
    OK, yes, I'm afraid in this respect this example may not accurately reflect my real problem. One of the reasons I wanted the class "VehicleDealer" to have those attributes is that it should be able to verify that it has all the information it needs to forward the real work to the Builder. This is because the actual job may be time consuming and I want to be able to throw errors immediately if the parameter set is incomplete or inconsistent, but maybe that's not such a good idea after all...
    I guess I could easily separate instantiating and running the builders so that I can have them check their parameters before running the job. Thanks for your help!