Summary on basis of the book ,,Design Patterns: Elements of Reusable Object-Oriented Software'', by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Addison-Wesley, 1995.
This is often used for conversions: the Director parses input data and calls the the Builder's methods for creating the object. The Builder's same methods are called multiple times for each piece of data. At the end we can retrieve constructed object from the Builder. We can have many different Builders, each converting to different format.
Variations:
class Direcor {We use this when we want to separate the algorithm for creating an object from the structure of the thing based on which we create it.
getRepresentation(){
...
for (..){
builder.addPart(in.readLine());
}
...
}
}
This is often used for conversions: the Director parses input data and calls the the Builder's methods for creating the object. The Builder's same methods are called multiple times for each piece of data. At the end we can retrieve constructed object from the Builder. We can have many different Builders, each converting to different format.
Variations:
- the example builder is in a step-by-step fashion, but that mat not be enough, e.g. some conversion cases; in such case the Builder can return to the Director the intermediate steps, which will then be passed back to the Builder, at proper time..
- there's no need for creating common interface for products - they vary too much, and the builders must know concrete classes anyways
- in superclass of all Builders the building methods do not have to be virtual (abstract) - they can just be empty; in such case the subclasses will implement only the parts they are interested in
Comments
Want to leave a comment? Visit this post's issue page
on GitHub and just post your comment as the issue's comment (you'll need a GitHub account. What? Like you don't have one yet?!).
Comments: