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

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:

  1. Deciding, and grading, their own fitness to a particular purpose.
  2. Understanding what all the relevant knobs, switches and flashing-lights are, for anyone whom they must deal with (both “the requestor” and “the device”).
  3. 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.