In this talk I'm going to start from the bottom up. We're going to find out what software design patterns are, and how we use them. Then we're going to focus on one design pattern in particular and analyse why and how you would use it.
In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.
The term "Design Pattern" was coined in the book Design Patterns: Elements of Reusable Object-Oriented Software written by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (affectionately known by the software engineering community as The Gang of Four).
The book is divided into two parts, with the first two chapters exploring the capabilities and pitfalls of object-oriented programming, and the remaining chapters describing 23 classic software design patterns with examples in C++ and Smalltalk.
In general, design patterns exist to provide reusable templates to solve common complex problems when writing code. These not only provide the developer with a reusable solution to draw on when solving hard problems, but also give other developers who know the design patterns a clue as to the nature of that solution later on.
However, a complex problem in one language is not necessarily as complex in another language. If another language can solve the same problem trivially, that other language won't have need of a design pattern for it. Users of that language may not even be aware that the problem exists, because, well, it's not a problem in that language.
This is what The Gang of Four have to say on the subject:
The choice of programming language is important because it influences one's point of view. Our patterns assume Smalltalk/C++-level language features, and that choice determines what can and cannot be implemented easily. If we assumed procedural languages, we might have included design patterns called "Inheritance", "Encapsulation," and "Polymorphism". Similarly, some of our patterns are supported directly by the less common object-oriented languages. CLOS has multi-methods, for example, which lessen the need for a pattern such as Visitor. In fact, there are enough differences between Smalltalk and C++ to mean that some patterns can be expressed more easily in one language than the other. (See Iterator for example.)
[Introduction to the Design Patterns, Page 4, Paragraph 3]
The builder pattern is an object creation software design pattern. This means it creates objects for the developer within an object orientated paradigm.
This is not the same as the abstract factory pattern and the factory method pattern whose intention is to enable polymorphism.
Polymorphism (n.) The provision of a single interface to entities of different types.
The intention of the builder pattern is to find a solution to the telescoping constructor anti-pattern that occurs when the increase of object constructor parameter combination leads to an exponential list of constructors.
Instead of using numerous constructors, the builder pattern uses another object, a builder, that receives each initialization parameter step by step and then returns the resulting constructed object at once.
...