The Builder design pattern solves problems like:
How can a class (the same construction process)
create different representations of a complex object?
See Applicability section for all problems Builder can solve. See Solution section for how Builder solves the problems.

• An inflexible way is to create and assemble the parts of a complex object (new ProductA1(), add to complex object, new ProductB1(), add to complex object, …) directly within a class (Client).
• This commits (couples) the class to creating a particular representation of the complex object (ProductA1, ProductB1), which makes it impossible to create a different representation (ProductA2, ProductB2, for example) independently from (without having to change) the class.
• That's the kind of approach to avoid if we want that a class (the same construction process) can create different representation of a complex object.
• For example, creating a bill of materials object (BOM).
  A bill of materials is organized into a part-whole hierarchy (see also Composite for representing a part-whole hierarchy). It describes the parts that make up a manufactured product and how they are assembled.
  A class should avoid instantiating concrete product classes directly so that it can create different product structures (representations) of the BOM.