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

Here are some “thoughts purely of my own” which come to my mind immediately when I read this ... and, mind you, I’m using my own made-up (I hope, common-sense) terminology.   Please don’t flip through design-pattern textbooks trying to figure out which one of those I am referring to.   This is coming from my own cranium.

It may be that you are exposing all of those attributes so that different other actors can make appropriate decisions using them.   The problem here is that every actor you meet has to be familiar with every product it may meet, either now or in the future.   Likewise, when new actors are invented, the logic which deals with “all those attributes” must be duplicated into them.   Pretty soon you have exactly the web of interdependency that you would like to avoid, even though it has been couched in the latest trendy metaphors.

Having spent a few seconds now groping for an analogy ...   For that purpose, I like to coin the notion of what I shall call an “apprentice.”   An apprentice is the fellow who tags along beside the master in the shop, helping the master out and in the process learning his trade.   The apprentice is also, quite admittedly, the “grunt.”   Well, in this case, apprentices are the folks who can answer a product’s specific questions about a builder, and a builder’s specific questions about a product, and who are able to determine whether they actually possess the knowledge necessary to speak-up in the first place.   There might be any number of these, and when there is a need to get an actor and a product together, we have to find the apprentice that is most knowledgeable – who is the “best fit.”

An apprentice, interviewing for the job as it were, might ask of the product, “do you have parameters X, Y, Z?”   And of the actor, “do you need to know A, B, C?”   Pause.   “Then I can help you, and my fitness score is 21.”

The purpose of the apprentice is to answer questions, and to do grunt work.   An arbitrary number of them can exist and perhaps more than one of them are participating at any time.   The complexity of this so-to-speak “cartesian join” is now wrapped-up in the implementation of the apprentice, and of the apprentice-selection heuristic.

I do not intend to suggest that “apprentice” is the best word to use here.   I didn’t read it in a book; I just now made it up.   In fact it really isn’t the best word or the best analogy.   The notion is basically that of a “plug-in, hot-swappable software subject-matter expert,” who enables the system to be flexible more-or-less “by committee.”   If a VehicleBuilder or even a VehicleBuyer needs to know the answer, they don’t have to have the logic to determine the answer themselves ... they just have to find someone who knows is the most confident that he has the answer, and then ask him to produce it.   I think that the germ of the idea is a sound one, and I do not proclaim it to be original.   (And if it does happen to be original, you will not be asked to buy my book nor to attend my seminar anytime soon.)

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 16:25 UTC

    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.... :-)

[reply]

      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.

In Section Seekers of Perl Wisdom