[ComponentDesignPatterns | CategoryPattern]

'''Context'''

Software developers with little or no experience with TheCraft and high-level of unfamiliarity with technologies being used to implement an application or system.  ComponentBasedDevelopment approach being used, and multiple components will be reused and developed.  A common support infrastructure or framework being reused or developed.  

'''Problem'''

Each component needs to tie together several third-party tools, technologies, and core infrastructure/framework classes common to each component.  Need to leverage inexperienced developers or non-technical types to manufacture all controls in a consistent manner.  Not a lot of room in the schedule for documentation.

'''Solution'''

Create a cookbook that contains groups of steps.  After each group of steps is completed, the developer validates the results through unit testing.  The result of successful completion of all groups is a fully functioning control.

'''Resulting Context'''

Developers iteratively test/code until a working control is built.  They repeat the process several times with the same consistent level of quality.  Remain aware of any refactoring and reengineering to ensure subsequent changes are reflected in the cookbook.  Other software developments can reuse it.  Managers buy team lots of beer for a job well done.

'''Known Uses'''

	* Janna [1], a third-party contact management application containing several domain-specific components developed with Visual C++/MFC, Rogue Wave Tools.h++, Iona Orbix, and ProtoView DataTable.

	* There was an early paper written by Glenn E. Krasner and Stephen T. Pope from Parcplace called, ``A Cookbook for Using the ModelViewController User Interface Paradigm in Smalltalk-80,'' (Journal of Object-Oriented Programming, May-June 1988, pp. 26-49) that many of us relied upon in the early days of Smalltalk for a step-by-step approach to building controls with the MVC framework.

----
In a discussion about CDP at Micromodeling Associates, we discussed CookbookApproach.  The name seemed to cause confusion.  I have created an equivalent pattern that is an attempt at a better name called AssemblyCookbook.  Let me know if this is better or if you have any other ideas.

The participants felt this was more of a process or decision-oriented pattern as opposed to a design pattern.  We already knew this, but I see that there's confusion based on the name "Component DESIGN Patterns" and the existence of patterns that aren't DesignPatterns.  Perhaps a good exercise both pre- and during-ChiliPLoP is to throw around name ideas.

One caveat mentioned was that there's a "hitting the wall" phenomenon where you are going along just fine following the rules and steps of the recipe, then suddenly it stops working.  People who are using this pattern who don't have the tools to know how to solve the problem will hit a wall.  Should this be a part of the resulting context?

Another comment was to look at the Visual Basic Programmer's Journal, since it seems to make heavy use of cookbooks.

--PhilipEskelin