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

That would be sort of simliar to the "Catalog" class I mentioned above in that the parameters taht go into a Vehicle are combined into their own class and can tehn be passed around as instances of it, right?
  • Comment on Re^2: Builder design pattern with lots of parameters - trying to declutter design

Replies are listed 'Best First'.
Re^3: Builder design pattern with lots of parameters - trying to declutter design
by jethro (Monsignor) on Mar 29, 2011 at 08:43 UTC

    Moose has introspection capabilities. Your VehicleDealer can find out what attributes a class has (even before that class is instantiated). If you name your attributes so that they can be identified (i.e. all configuration attributes of class car have a prefix of 'config_') or if simply all attributes of class car are to be configured by VehicleDealer, you don't need any of the attributes in VehicleDealer nor any intermediate classes with attribute lists.

    Even without introspection I would just have a class method in car and motorbike that just returns all the attributes it possesses. So that the information is kept in one place only.

      This may be part of why I decided that sales was not for me:   I was going to be constantly attending product-training classes, for a company that sold a tremendous variety of things.   Even in the present analogy, “cars” and “motorbikes” are not the same thing, except to the extent that both have wheels, they might be colored red, and they can go very fast.   Even though the dealer, in our example, can “introspect” (i.e. “plainly see”) both objects and determine, for example, the number of wheels that each one possesses, that Dealer is still constantly going to be attending new product-training courses.   And in so doing, constantly growing in complexity and declining in maintainability.   It may well be argued that this is where spaghetti comes from.   It truly is a very complex problem, and I do not mean to trivialize it (let alone to suggest that my wild-haired idea has any actual relevance upon it).   But I have encountered the consequences of designs (as we all have...) many times.   “The fact that both of them are, say, ‘vehicles,’ is useful only to a point.”   Our purpose is to build easily-extendable code that will last a dozen years, not to count wheels, and, that’s hard.   While these metaphors do have merit, and are generally worthy based on these merits that they have, they are not the full solution.

      (And so, realizing that I have made no specific conclusion here, I shall now climb down off of this box and put it away.)

        The hope is that the dealer may, without any knowledge whatsoever about those items, just put a list in front of the client to answer. The only thing he knows is how to contact the builder with that filled out list and how to get the finished product into the hands of the client.

      Good point - thanks a lot!