In our fictional world we sometimes have some rather complicated classes, which need to be constructed. The classes contain different implementations of an interface depending on how they are constructed. In order to simplify the building of these classes and encapsulate the knowledge about building the class away from the consumers, a builder may be used. Multiple concrete builders reduce the complexity of the constructor in the implementation. When new builders are required, a constructor does not need to be added, a new builder just needs to be plugged in.
Tournaments are an example of a complicated class. Each tournament has a complicated setup involving the events, the attendees, and the prizes. Much of the setup for these tournaments is similar: each one has a joust, archery, and a melee. Creating a tournament from multiple places in the code means that the responsibility for knowing how to construct a tournament is distributed. If there is a need to change the initiation code then it must be done in a lot of different places.
Employing a builder pattern avoids this issue by centralizing the logic necessary to build the object. Different concrete builders can be plugged into the builder to construct different complicated objects. The relationship between the various classes in the builder pattern is shown here:
Let's drop in and look at some of the code. To start with, we'll create a number of utility classes, which will represent the parts of a tournament as shown in the following code:
let Event = (function () {
function Event(name) {
this.name = name;
}
return Event;
})();
Westeros.Event = Event;
let Prize = (function () {
function Prize(name) {
this.name = name;
}
return Prize;
})();
Westeros.Prize = Prize;
let Attendee = (function () {
function Attendee(name) {
this.name = name;
}
return Attendee;
})();
Westeros.Attendee = Attendee;The tournament itself is a very simple class as we don't need to assign any of the public properties explicitly:
let Tournament = (function () {
this.Events = [];
function Tournament() {
}
return Tournament;
})();
Westeros.Tournament = Tournament;We'll implement two builders which create different tournaments. This can be seen in the following code:
let LannisterTournamentBuilder = (function () {
function LannisterTournamentBuilder() {
}
LannisterTournamentBuilder.prototype.build = function () {
var tournament = new Tournament();
tournament.events.push(new Event("Joust"));
tournament.events.push(new Event("Melee"));
tournament.attendees.push(new Attendee("Jamie"));
tournament.prizes.push(new Prize("Gold"));
tournament.prizes.push(new Prize("More Gold"));
return tournament;
};
return LannisterTournamentBuilder;
})();
Westeros.LannisterTournamentBuilder = LannisterTournamentBuilder;
let BaratheonTournamentBuilder = (function () {
function BaratheonTournamentBuilder() {
}
BaratheonTournamentBuilder.prototype.build = function () {
let tournament = new Tournament();
tournament.events.push(new Event("Joust"));
tournament.events.push(new Event("Melee"));
tournament.attendees.push(new Attendee("Stannis"));
tournament.attendees.push(new Attendee("Robert"));
return tournament;
};
return BaratheonTournamentBuilder;
})();
Westeros.BaratheonTournamentBuilder = BaratheonTournamentBuilder;Finally the director, or as we're calling it TournamentBuilder, simply takes a builder and executes it:
let TournamentBuilder = (function () {
function TournamentBuilder() {
}
TournamentBuilder.prototype.build = function (builder) {
return builder.build();
};
return TournamentBuilder;
})();
Westeros.TournamentBuilder = TournamentBuilder;Again you'll see that the JavaScript implementation is far simpler than the traditional implementation due to there being no need for interfaces.
Builders need not return a fully realized object. This means that you can create a builder which partially hydrates an object then allows the object to be passed on to another builder for it to finish. A good real world analogy might be the manufacturing process for a car. Each station along the assembly line builds just a part of the car before passing it onto the next station to build another part. This approach allows for dividing the work of building an object amongst several classes with limited responsibility. In our example above we could have a builder that is responsible for populating the events and another that is responsible for populating the attendees.
Does the builder pattern still make sense in view of JavaScript's prototype extension model? I believe so. There are still cases where a complicated object needs to be created according to different approaches.