Tuesday, February 16, 2010

Builder Pattern

This post is the first of (hopefully) many outlining my exploration of Design Patterns, and how they can be used within my employer's production code. I'll abstract away any details (can't give away secrets), but will try to provide enough to give the general idea. These posts won't go into detail on the actual patterns themselves, but will provide references to sites that do explain things in detail.

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

http://www.dofactory.com/topic/search.aspx?q=builder

http://en.wikipedia.org/wiki/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:

ConnectOrderOrchestrator.Build

Which would do something like:
  1. Retrieve Existing Information
  2. Construct Order Form
  3. 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...
Posted by at
Labels:

2 comments:

  1. Professor Marty,

    I think I have a similar issue with builder/factory patterns. I think the piece I am missing is the benefit. I don't think having a Builder class would be bad, but why stop there? Why not break everything up into different classes (obviously this becomes more complex and that is why)? Couldn't you do everything you need to do with constructors or static/instance methods off the class or parent class? Why bother with an entirely different class? Is it to break out the business logic and the data model? It doesn't seem like it would hurt, but I don't see the benefit. If I could, I think that would also help me see places where I should be doing it.

    I had a buddy I used to work with named Carter (for his privacy, we'll say his last name was McScrooge). I believe he was a big fan of builders, but I never got a chance to have him explain it to me. If you can track him down and get him to respond here, that would be great. I do feel like I'm missing out on something that others seem to understand and if it can help me, I'd love to understand as well.

    Plus I just miss McScrooge.

    ReplyDelete

  2. Short answer is the Single Responsibility principle - a class should have one reason to exist. If you're class is:

    1) Building something
    2) Using that something to execute business logic

    Then #1 should probably be done by someone else. In the simple scenario, it's overkill, but when you have a complicated hierarchy of dependencies, etc, it can get pretty burdensome to "build" something. This really starts to rear it's head in unit testing - if half your unit test involves constructing things that are used by the "meat" of your logic, then that might need to be offloaded to another class.

    ReplyDelete

Subscribe to: Post Comments (Atom)