Design Patterns by Gamma, Helm, Johnson, and Vlissides could possibly be the “holy grail” of software development books. Most practitioners of the software craft have read it and a good many have it sitting on their bookshelves. It has even spawned the “rock star” t-shirt seen here. Robert C. Martin has talked about it, and so has Martin Fowler, Joshua Bloch, Grady Booch, and many others.
Of the design patterns, I would guess that Singleton (127) or Abstract Factory (87) are the most widely used. Perhaps Strategy (315) is also in there somewhere. Not far behind, I would think, is Builder (97). Yet I would argue that Builder (97) is still an underused pattern. I see a lot of code around that would benefit from Builder (97).
By the way, for those of you wondering, yes that is the way these design patterns are commonly notated. The parenthetical number is the page in Design Patterns where the pattern can be found! Builder (97) means the builder pattern, found on page 97 of Design Patterns.
A quick, easy, and widely applicable example of when to use the builder pattern in web development is in form validation. Fair warning, though! It is going to take some time to get around to demonstrating the need for the builder pattern in this example. Read on and we’ll get there, eventually!
I actually just did something like this the other day. Let’s say you have a POJO to represent a form where someone filled in their name, email address, and birthday.
For the sake of this example, let’s assume there are three kinds of validation needed here. The first, obvious validation needed is that all fields are required, and so can’t be blank.
So maybe just to handle the required fields thing, you add a couple of simple methods and end up with something like this:
You can see where this is heading. You’re about to add a bunch of methods into your class just around validation. You should put that in a separate class. That’s just good design, it has nothing to do with the builder pattern. Since this validation really applies to just this object, then, at least for now, you can add validation as an inner class to this POJO.
As you’re about ready to do that, you get a visit from your product manager who tells you they want to test whether not collecting birth date is having an impact on number of forms completed. Never mind that of course this will be the case. This is a contrived example.
The consequence of this decision is that there are now going to be two forms. In the first form, birth date is still required, but in the second form, only first name and birth date are required. Now you have to sometimes validate birth date and sometimes not.
How are you going to do it? You could do something janky like this:
Now this is just getting really ugly! Not to mention that, ideally, you want a way to more easily handle any future changes around required fields. You need a flexible way to add validation. A better solution might look like this:
As you can see there is missing code here, because I skipped ahead a bit to how we would like our code to look. We have added a reference to the “Validator” class, which very well may be implemented as an inner class like we referenced above. Now we have a way to let the client of our POJO inject which fields are required through the “requiredFields” parameter on the constructor. Second, we don’t worry about dealing with the validation in the POJO anymore. It is a responsibility that is delegated to our Validator class.
Since this post is long enough for now, I’ll leave this one on a cliffhanger and come back and implement this in part 2, with the builder pattern.