...and to start things off.....The Builder Pattern!
The Builder pattern essentially delegates the construction of complicated entities to specialized classes that know how to construct them. Here are some sites outlining the Builder pattern:
Some of my thoughts on the Builder pattern:
- Useful when the construction of an object (ie, the "Product") requires a series of steps. eg, something like "Build Tree, Populate Nodes, Sum Totals". If the "Product" is simple, and doesn't require these steps, the Builder pattern doesn't seem to apply.
- Useful when there are several "varieties" of "Product" that can be build. For example, if we have an abstract "Vehicle" class, with concrete "Car", "Motorcycle", "RV", etc.
For application of this pattern, I'm currently struggling to find a good application. I mainly work on an Ordering system, and I'm not sure there's an obvious use. I considered the fact that we have different types of Orders (eg, New, Change, Supplement, etc), but they all seem to use the same core "contract" to carry the Ordering information. If we had an overarching "Orchestrator" of sorts, we could potentially use Builder for constructing the Orchestrator. It might look something like this:
Which would do something like:
- Retrieve Existing Information
- Construct Order Form
- Apply Defaulting
Then each Order Type could have their own Builder that walks through this same series of steps? I don't know, though - kind of seems like fitting a square peg into a round hole.
For now, I'm going to put this one in the back of my mind. As I work on code, hopefully something will jump out at me...