The builder pattern is a design pattern that provides a flexible solution to various object creation problems in object-oriented programming. The builder pattern separates the construction of a complex object from its representation. It is one of the 23 classic design patterns described in the book Design Patterns and is sub-categorized as a creational pattern. [1]
The builder design pattern solves problems like: [2]
Creating and assembling the parts of a complex object directly within a class is inflexible. It commits the class to creating a particular representation of the complex object and makes it impossible to change the representation later independently from (without having to change) the class.
The builder design pattern describes how to solve such problems:
Builder
object.Builder
object instead of creating the objects directly.A class (the same construction process) can delegate to different Builder
objects to create different representations of a complex object.
The intent of the builder design pattern is to separate the construction of a complex object from its representation. By doing so, the same construction process can create different representations. [1]
Advantages of the builder pattern include: [3]
Disadvantages of the builder pattern include: [3]
In the above UML class diagram, the Director
class doesn't create and assemble the ProductA1
and ProductB1
objects directly. Instead, the Director
refers to the Builder
interface for building (creating and assembling) the parts of a complex object, which makes the Director
independent of which concrete classes are instantiated (which representation is created). The Builder1
class implements the Builder
interface by creating and assembling the ProductA1
and ProductB1
objects.
The UML sequence diagram shows the run-time interactions: The Director
object calls buildPartA()
on the Builder1
object, which creates and assembles the ProductA1
object. Thereafter, the Director
calls buildPartB()
on Builder1
, which creates and assembles the ProductB1
object.
A C# example:
/// <summary>/// Represents a product created by the builder./// </summary>publicclassBicycle{publicBicycle(stringmake,stringmodel,stringcolour,intheight){Make=make;Model=model;Colour=colour;Height=height;}publicstringMake{get;set;}publicstringModel{get;set;}publicintHeight{get;set;}publicstringColour{get;set;}}/// <summary>/// The builder abstraction./// </summary>publicinterfaceIBicycleBuilder{BicycleGetResult();stringColour{get;set;}intHeight{get;set;}}/// <summary>/// Concrete builder implementation./// </summary>publicclassGTBuilder:IBicycleBuilder{publicBicycleGetResult(){returnHeight==29?newBicycle("GT","Avalanche",Colour,Height):null;}publicstringColour{get;set;}publicintHeight{get;set;}}/// <summary>/// The director./// </summary>publicclassMountainBikeBuildDirector{privateIBicycleBuilder_builder;publicMountainBikeBuildDirector(IBicycleBuilderbuilder){_builder=builder;}publicvoidConstruct(){_builder.Colour="Red";_builder.Height=29;}publicBicycleGetResult(){returnthis._builder.GetResult();}}publicclassClient{publicvoidDoSomethingWithBicycles(){vardirector=newMountainBikeBuildDirector(newGTBuilder());// Director controls the stepwise creation of product and returns the result.director.Construct();BicyclemyMountainBike=director.GetResult();}}
The Director assembles a bicycle instance in the example above, delegating the construction to a separate builder object that has been given to the Director by the Client.
Design Patterns: Elements of Reusable Object-Oriented Software (1994) is a software engineering book describing software design patterns. The book was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword by Grady Booch. 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. The book includes examples in C++ and Smalltalk.
The abstract factory pattern in software engineering is a design pattern that provides a way to create families of related objects without imposing their concrete classes, by encapsulating a group of individual factories that have a common theme without specifying their concrete classes. According to this pattern, a client software component creates a concrete implementation of the abstract factory and then uses the generic interface of the factory to create the concrete objects that are part of the family. The client does not know which concrete objects it receives from each of these internal factories, as it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from their general usage and relies on object composition, as object creation is implemented in methods exposed in the factory interface.
In software engineering, the adapter pattern is a software design pattern that allows the interface of an existing class to be used as another interface. It is often used to make existing classes work with others without modifying their source code.
The bridge pattern is a design pattern used in software engineering that is meant to "decouple an abstraction from its implementation so that the two can vary independently", introduced by the Gang of Four. The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.
In computer programming, the flyweight software design pattern refers to an object that minimizes memory usage by sharing some of its data with other similar objects. The flyweight pattern is one of twenty-three well-known GoF design patterns. These patterns promote flexible object-oriented software design, which is easier to implement, change, test, and reuse.
In object-oriented programming, the factory method pattern is a design pattern that uses factory methods to deal with the problem of creating objects without having to specify their exact classes. Rather than by calling a constructor, this is accomplished by invoking a factory method to create an object. Factory methods can be specified in an interface and implemented by subclasses or implemented in a base class and optionally overridden by subclasses. It is one of the 23 classic design patterns described in the book Design Patterns and is subcategorized as a creational pattern.
The prototype pattern is a creational design pattern in software development. It is used when the types of objects to create is determined by a prototypical instance, which is cloned to produce new objects. This pattern is used to avoid subclasses of an object creator in the client application, like the factory method pattern does, and to avoid the inherent cost of creating a new object in the standard way when it is prohibitively expensive for a given application.
In software engineering, the composite pattern is a partitioning design pattern. The composite pattern describes a group of objects that are treated the same way as a single instance of the same type of object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.
In object-oriented programming, the decorator pattern is a design pattern that allows behavior to be added to an individual object, dynamically, without affecting the behavior of other instances of the same class. The decorator pattern is often useful for adhering to the Single Responsibility Principle, as it allows functionality to be divided between classes with unique areas of concern as well as to the Open-Closed Principle, by allowing the functionality of a class to be extended without being modified. Decorator use can be more efficient than subclassing, because an object's behavior can be augmented without defining an entirely new object.
In object-oriented programming, the iterator pattern is a design pattern in which an iterator is used to traverse a container and access the container's elements. The iterator pattern decouples algorithms from containers; in some cases, algorithms are necessarily container-specific and thus cannot be decoupled.
In software engineering, the mediator pattern defines an object that encapsulates how a set of objects interact. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior.
In software design and engineering, the observer pattern is a software design pattern in which an object, named the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.
In computer programming, the strategy pattern is a behavioral software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives runtime instructions as to which in a family of algorithms to use.
In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or in added complexity to the design due to inflexibility in the creation procedures. Creational design patterns solve this problem by somehow controlling this object creation.
In software engineering, dependency injection is a programming technique in which an object or function receives other objects or functions that it requires, as opposed to creating them internally. Dependency injection aims to separate the concerns of constructing objects and using them, leading to loosely coupled programs. The pattern ensures that an object or function that wants to use a given service should not have to know how to construct those services. Instead, the receiving "client" is provided with its dependencies by external code, which it is not aware of. Dependency injection makes implicit dependencies explicit and helps solve the following problems:
In object-oriented programming, a factory is an object for creating other objects; formally, it is a function or method that returns objects of a varying prototype or class from some method call, which is assumed to be new. More broadly, a subroutine that returns a new object may be referred to as a factory, as in factory method or factory function. The factory pattern is the basis for a number of related software design patterns.
In programming languages, an abstract type is a type in a nominative type system that cannot be instantiated directly; by contrast, a concrete typecan be instantiated directly. Instantiation of an abstract type can occur only indirectly, via a concrete subtype.
In software engineering, a fluent interface is an object-oriented API whose design relies extensively on method chaining. Its goal is to increase code legibility by creating a domain-specific language (DSL). The term was coined in 2005 by Eric Evans and Martin Fowler.
Vala is an object-oriented programming language with a self-hosting compiler that generates C code and uses the GObject system.
In object-oriented design, the chain-of-responsibility pattern is a behavioral design pattern consisting of a source of command objects and a series of processing objects. Each processing object contains logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain. A mechanism also exists for adding new processing objects to the end of this chain.