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

My take on this is that you are making the mistake of trying to encapsulate program logic into your class hierarchy.

That is, you are trying to avoid

my $dealer; if( $vehicleType eq 'car' ) { $dealer = CarDealer->new(); { elsif( $vehicleType eq 'bike' ) { $dealer - BikeDealer->new(); } else { die "Unknown Vehicle type: $vehicleType"; }

And by doing so, you are pushing the decision into the class hierarchy and compounding its complexity in the process.

There simply isn't enough commonality between the two to root them in a common ancestry.

For (say) a supermarket where the only variables in a purchase might be pack size and quantity, it might make some sense; but for something with as many configurable options as cars and bikes, using inheritance to avoid an early boolean decision seems like a Code Smell of the contrived complexity variety.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re: Builder design pattern with lots of parameters - trying to declutter design
  • Download Code

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:47 UTC
    Thanks for your reply!
    In my real application there is maybe a bit more communality but I'd say even in this example there probably is. Even in the real world you may find VehicleDealers who do cars and bikes because all they need to do is call up the builder/factory to make a vehicle and maybe give them some of the details such as colour, and these are mostly the same options for both types of vehicles. As far as I can see, if I used your example, I would still end up dealing with pretty much the same parameters/attributes in the concrete builders and product classes, which was my original problem. However, I think that the mistake was to try and make the builders check those attributes instead of letting the product classes deal with it.