Re^2: Builder design pattern with lots of parameters

So in essence you would create additional classes that are basically ParameterHandlers (maybe "Catalogs" would be an analogy that would fit here?), is that correct? Directors and Builders would then only need to use the same Catalog to determine what they can and should know about the object to be created.

If I understand you correctly then this is something I also thought about. The advantage would be that it would be clearer where to find these parameters and not be surprised if an object of a class has lots of attributes that come from its various mixed-in roles.
Maybe this isn't at all what you meant but I think I'm warming up to the idea anyway.... :-)

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 locked_user sundialsvc4 (Abbot) on Mar 28, 2011 at 17:39 UTC
This idea is “not even half-baked ... it’s raw dough.” I don’t think that “Catalog” is a good metaphor, because, in the real world, “a catalog” is a thing that you use, while it just sits there. What I am describing here is an active thing: an intermediary, a concierge, a lackey, a grunt, an engineer on the butt end of the org chart. Essentially, you have a bunch of “players” here ... cars, dealers, factories and so-on ... “that have to be able to get their questions answered and to do things.” Furthermore, all of these various groups of players are constantly changing as the application evolves. So you create a concept of specific intermediaries ... a “secretarial pool” of experts who can be called-upon, first to decide if they can help you, then to help you if they can. You can engage as many of them as you need. These so-called “lackeys” are, of course, as mission-critical as they are unsung. (’Twas ever thus...) They bear the triple responsibility of: Deciding, and grading, their own fitness to a particular purpose. Understanding what all the relevant knobs, switches and flashing-lights are, for anyone whom they must deal with (both “the requestor” and “the device”). Concealing all of that irrelevant detail from all parties concerned, so that they can accomplish their purpose without raising their scalp above the top-edge of the trenches. I am attracted to the idea because that more-or-less is how things work in the real world (of engineering). No matter who you are, you cannot know everything and you cannot afford to learn it. So, the task quickly becomes, “find someone who knows.” Since you, of course, do not know how to judge who is qualified and who is not (and since that can change at any time without your ability to know), you put forth a cattle-call and ask for volunteers to step forward. We can always put forth a more-conventional design that exploits what we today know to be similarities and differences between “cars” and “motorbikes,” but over (a sometimes short period of time) those assumptions become strained. An executive suddenly decides that it’s a great idea for the company to start producing microwave ovens, or yogurt, and presto, it is done. In a real-world situation (after burying the aforesaid executive under a great mound of cheese), the company would be amassing a multi-disciplinary group of people who do know how to fill the gaps of knowledge and expertise. We have not taught the old dogs new tricks. Instead, we have enabled everyone to adapt themselves to this discipline, which can accommodate yogurt-making and car-making under the same roof.

Replies are listed 'Best First'.

Re^3: Builder design pattern with lots of parameters - trying to declutter design
by locked_user sundialsvc4 (Abbot) on Mar 28, 2011 at 17:39 UTC

This idea is “not even half-baked ... it’s raw dough.”

I don’t think that “Catalog” is a good metaphor, because, in the real world, “a catalog” is a thing that you use, while it just sits there. What I am describing here is an active thing: an intermediary, a concierge, a lackey, a grunt, an engineer on the butt end of the org chart.

Essentially, you have a bunch of “players” here ... cars, dealers, factories and so-on ... “that have to be able to get their questions answered and to do things.” Furthermore, all of these various groups of players are constantly changing as the application evolves. So you create a concept of specific intermediaries ... a “secretarial pool” of experts who can be called-upon, first to decide if they can help you, then to help you if they can. You can engage as many of them as you need.

These so-called “lackeys” are, of course, as mission-critical as they are unsung. (’Twas ever thus...) They bear the triple responsibility of:

Deciding, and grading, their own fitness to a particular purpose.
Understanding what all the relevant knobs, switches and flashing-lights are, for anyone whom they must deal with (both “the requestor” and “the device”).
Concealing all of that irrelevant detail from all parties concerned, so that they can accomplish their purpose without raising their scalp above the top-edge of the trenches.

I am attracted to the idea because that more-or-less is how things work in the real world (of engineering). No matter who you are, you cannot know everything and you cannot afford to learn it. So, the task quickly becomes, “find someone who knows.” Since you, of course, do not know how to judge who is qualified and who is not (and since that can change at any time without your ability to know), you put forth a cattle-call and ask for volunteers to step forward.

We can always put forth a more-conventional design that exploits what we today know to be similarities and differences between “cars” and “motorbikes,” but over (a sometimes short period of time) those assumptions become strained. An executive suddenly decides that it’s a great idea for the company to start producing microwave ovens, or yogurt, and presto, it is done. In a real-world situation (after burying the aforesaid executive under a great mound of cheese), the company would be amassing a multi-disciplinary group of people who do know how to fill the gaps of knowledge and expertise. We have not taught the old dogs new tricks. Instead, we have enabled everyone to adapt themselves to this discipline, which can accommodate yogurt-making and car-making under the same roof.